Writing by Ben Zipkin (https://benzipkin.com) --- # Doctors Stopped Googling. Most Pharma Marketers Haven't Noticed. URL: https://benzipkin.com/writing/openevidence-doctors-stopped-googling Date: 2026-10-22 Tags: aeo, ai-search I spend a lot of time looking at how pharma brands show up in search and AI answers. Almost all of that work has focused on two audiences: patients typing into Google, and patients asking ChatGPT. A study published in *JAMA* last week made me realize I'd been underweighting a third. Researchers looked at clinicians using OpenEvidence, an AI tool that answers clinical questions from the medical literature. Between January 2024 and June 2026, about 952,000 verified US clinicians sent it 271 million questions. Monthly users went from a few hundred to more than 700,000. The number that stuck with me is a different one. A third of those questions were about treatment and management, compared with about 14% for diagnosis. Clinicians aren't using it to work out what a patient has. They're using it to decide what to do next. That's the moment pharma marketing has always tried to reach, and it now happens inside a tool most brand teams have never opened. A few things about this feel different from the usual "AI is changing search" story. **The people asking aren't the ones brand plans are built around.** Nurse practitioners and PAs ask more questions per month than physicians do. Early-career doctors use it far more than their share of the workforce would suggest. Many of these are HCPs a rep rarely sees. **The answers don't come from brand websites.** OpenEvidence draws on published evidence, and this week Doximity said it's bringing UpToDate content into its own AI tool. The HCP site you spent a year optimizing may barely factor in. What matters is whether the label, the studies, and the guidelines say the right thing clearly. **None of it shows up in your analytics.** A clinician who gets a full answer doesn't click through. If your dashboard reads HCP site traffic as a sign of interest, it's quietly missing more every month. I don't think the answer is to panic or to rush to buy ads in these tools. The first step is simpler: ask them the questions your HCPs actually ask, read what comes back, and check whether it's accurate. Most teams I talk to haven't done that once. I wrote up the full findings and a five-step plan for pharma teams on the PharmaForward site: [OpenEvidence Is the New HCP Search Engine. Here's What Pharma Should Do About It.](https://pharmaforward.com/thinking/openevidence-pharma-hcp-ai-search/) --- # ChatGPT ads are open for business. Pharma mostly isn't on the list. URL: https://benzipkin.com/writing/chatgpt-ads-pharma Date: 2026-10-12 Tags: paid-search, aeo Every brand team I talk to is asking whether they should buy ChatGPT ads. For a prescription brand, the answer right now is no, because you can't. There's a narrow unbranded lane that may be worth testing, and a bigger opportunity that doesn't involve buying media at all. ## Where things stand OpenAI started testing ads in the US on February 9, 2026, on the Free and Go plans. Plus, Pro, Business, Enterprise, and Edu accounts don't get ads, and neither do Temporary Chats or users identified as under 18. Ads appear below a response and are labeled as sponsored. In May, OpenAI launched a beta self-serve Ads Manager, added CPC bidding on top of CPM, and announced a Conversions API and pixel. On August 31 it reported a $1 billion annualized run rate. As of September 23, it says ads are available in more than 60 countries. Ads are matched mostly on the current conversation, plus general location, the advertiser's targeting choices, and past chats if the user has personalization turned on. OpenAI hasn't published a full list of targeting options, and I've seen nothing about HCP targeting. ## What the health policy says Read the [ad policies](https://openai.com/policies/ad-policies) yourself; they've been revised six times since March. Here's what matters for pharma. Regulated medical products and treatment claims are restricted, and prescription drugs aren't on the allowed list, so branded Rx is out. Health ads are US only and approved one by one. Allowed categories include devices and apps, diagnostics, insurance, hospitals, and "disease awareness campaigns that do not advocate for public policy." Unapproved products and "experimental or investigational therapies" are banned. The policy doesn't mention trial recruitment, so ask OpenAI before you assume either way. Advertiser eligibility is a separate check. Companies whose primary business falls in a restricted category, with healthcare named as an example, "may be ineligible." A manufacturer may not get approved even for unbranded work. Placement is its own filter. No ads appear in "mental and personal health conversations." General medical-advice chats haven't been blocked by default since April. But "I was just diagnosed with..." counts as personal, and that's where most patient intent sits. Even an approved advertiser only shows up next to general health conversations, and OpenAI's classifier decides which ones qualify. ## What's realistically possible Unbranded disease awareness is the one path the policy names. That means symptom literacy or what a specialist workup involves, linked to an unbranded site. It still needs MLR review, and OpenAI reviews the landing page too. Diagnostics are a named category. That matters if you or a partner sells a test. HCPs: mostly no. There's no profession targeting, and clinicians on enterprise or paid accounts never see ads. Copay and support programs: assume no. A copay card names the product, which makes it promotion. ## Questions for MLR Adjacency. Your ad sits under an answer you didn't write and can't preview. If that answer names a competitor's drug, does your ad imply a comparison? Decide, and document it. Conversations. Users can "Ask ChatGPT" about an ad, and they can message an advertiser through it. Those messages need adverse-event and medical-information routing. Pixels on health pages. Reporting is aggregated, but OpenAI's pixel on a disease site is still a third-party tag on a health property. Have privacy counsel review it. Policy churn. Check the changelog before every flight. FDA is also moving to tighten DTC drug advertising rules, so keep any test unbranded and boring. ## How you'd know it worked You get CPM or CPC delivery and aggregated conversions. Pick one action on the unbranded site as the conversion, such as a discussion-guide download. Set a cost ceiling and compare against your search baseline. If you can't define the action before launch, you aren't ready to buy. ## Paid placement won't get you into the answer OpenAI says ads "do not influence ChatGPT's answers." Take that at face value: an ad does nothing for whether you're cited in the answer above it. Patients read that answer first, and many of their decisions happen in personal health chats that never carry ads. In our audits, the sources behind that answer are often advocacy groups, reference publishers, and competitors' unbranded content. Getting your MLR-approved language into that source layer will do more for you than an ad underneath it. ## Takeaway For Rx brands, ChatGPT ads are mostly closed. If OpenAI approves you, test unbranded disease awareness and measure it like any new channel. Spend most of your effort on the answer itself. --- # I built a no-code patient-insight tool in 20 minutes URL: https://benzipkin.com/writing/no-code-patient-insight-tool Date: 2026-09-28 Tags: aeo, martech Most AI tools hand you an answer and stop there. The more interesting move is to build a specialist you can reuse — one that follows the rules your industry actually runs on — and then hand it to someone else. It took about twenty minutes, no code, and I pointed it at a question I care about: what do patients ask about their condition, and does anyone answer them where they're looking? I did it with Grok Bot, an AI assistant that can research the web, work with files, run tasks in the background, and remember how you like things done. I described what I wanted and we built it in conversation. ## Building it was a conversation, not a project I told it I wanted a bot focused on AEO and SEO for biopharma. From there it mostly built itself: - It set its own guardrails — stay on-label, flag everything for MLR review, never invent a number. - It saved repeatable skills for a visibility audit and for patient-question mining, so the workflow runs the same way every time instead of depending on how I happen to phrase the prompt. - When I asked what else it could do, it pitched options and I picked. The strategist-facing additions — patient-journey mapping, unmet-need insights, competitor sentiment, monthly trend tracking — came out of that back-and-forth. - It packaged the whole thing into a shareable template with a short onboarding chat, so someone else can install their own copy and get running. That last part is the point. A one-off prompt is a party trick. A guardrailed workflow you can hand to a colleague is a tool. ## What it found on sickle cell I asked it to run on sickle cell disease and kept working while it went. A few minutes later it came back with: - **90 real patient and caregiver questions**, pulled from Reddit, Google, and advocacy sites and grouped by theme. - **Content gaps** where patients ask constantly but only journal articles answer — life expectancy, ER care, gene therapy versus transplant. These are exactly the questions an answer engine has to source from somewhere, and right now it isn't sourcing them from brands. - **A major health system page still listing a treatment withdrawn in 2024.** Stale content that engines and patients are both still reading. - **8 plain-language FAQ drafts**, each with sources, marked for MLR review — a starting point for review, not published copy. - Posts that read like possible **adverse-event reports**, set aside for a safety team instead of being mined for content. - A spreadsheet with all of it. It was also honest about what it couldn't see — Google's AI Overviews, for one — and said so instead of guessing. In a regulated context, a tool that names its blind spots is worth more than one that papers over them. ## Why it matters Every other channel in pharma has an owner and a workflow. The answer layer — what patients read before they reach any brand site — mostly doesn't. A small, guardrailed specialist that mines the real questions and flags the compliance edges is how you start treating that layer like a channel instead of a mystery. For marketers, strategists, and agencies, that's the difference between a clever demo and something a team actually uses. ## Try it I packaged mine as **[Patient Convo Tracker](https://x.ai/bot/xfE5ddKdJ3qQcKN6o2EZI)**. Install it, give it a condition you work on, and see what your patients are actually asking. If you build your own for a different use case, I'd like to see it. --- # Everyone agreed AI needs accuracy. Nobody showed the scorecard. URL: https://benzipkin.com/writing/ai-answer-layer-scorecard Date: 2026-09-19 Tags: aeo, geo, measurement I once sat inside an account reporting a 76% paid search conversion rate. Nobody had questioned it. Month after month it went into the deck, and month after month it got approved, because a number that good does not invite scrutiny. The inflation was ordinary. Imported micro-events counted as conversions. Locator taps double-counted. Smart Bidding pointed at the resulting noise, which meant the algorithm spent real money optimizing toward a fiction. Data that flatters does not get audited. Data that disappoints does. That asymmetry is the most expensive thing in digital marketing, and it has just moved to a new layer. MM+M's preview of Fierce Pharma Week said the industry was done with AI as spectacle. The agenda would be accuracy, measurement, and whether brands are completely represented in the answers large language models give patients and clinicians. That is the right conversation. It is also the one the industry has not operationalized. What shipped around the same week was more machinery. DeepIntent opened Cora, an agentic planning and activation layer where brands and agencies share a workspace. The Trade Desk pushed Crossix and IQVIA signals deeper into the buy path, with Gross NBRx optimization coming later this year. Doceree launched an Intent Powered HCP Suite promising clinical intent across CTV, LinkedIn, and programmatic. Assembled Intelligence named Andrea Palmer, formerly of Publicis Health Media, as CEO and waved GEO and answer-engine omnichannel as part of the story. Genentech's CMO said new marketer measurement tools arrive in December. None of it is unserious. All of it is the same pattern: more tools that report on themselves, and no independent scorecard for the layer that now sits upstream of the website. ## The agency gap Every holding company now has an AI practice, a chief AI officer, and a deck that opens with "AI-first." Almost none of them have an AI line item in a scope of work. Ask your AOR a direct question: who on this team owns whether our brand is cited accurately in AI answers? In most rooms the answer is a pause, then a name from the SEO pod, then a follow-up meeting. The people who wrote the AI strategy deck are frequently not the people who could tell you whether the brand site is crawlable by the engines doing the citing. That is not incompetence. It is incentive. Agencies are compensated for production, and the answer layer has nothing to produce. No asset, no MLR job number, no trafficking sheet. A channel that generates no deliverable does not get staffed, and what does not get staffed does not get measured. ## The compliance problem nobody has a code for Presence without on-label accuracy is not an AEO win. It is a compliance incident with distribution. When a caregiver triggers an AI Overview on an unbranded disease-state query and the engine lifts your efficacy language while dropping the boxed warning, that extract is in front of a patient. It carries your brand. It did not go through MLR, because there is no review code for it. Your team reviewed the page. The engine published the paraphrase. Every other channel has an owner and a workflow. The answer layer has neither. It is the only surface where brand language reaches patients and physicians with nobody accountable for what survives summarization. It is also not one surface. Consumer ChatGPT, clinician-facing deployments, and enterprise healthcare instances return different answers to the same question. A brand can look fine in an AI Overview and be invisible to a physician asking a clinical question. Treating GEO as a single line item is how you get a false green on a dashboard. ## Four questions worth an afternoon **On our priority unbranded queries, who gets cited today in Google AI Overviews?** Pull your top 20 unbranded disease-state queries and run each one logged out, capturing the cited domains in the AI Overview. It is common for that citation set to be dominated by third-party health publishers, advocacy organizations, and payer sites, with the manufacturer's own site absent entirely. **Who gets cited in consumer ChatGPT versus clinician-facing deployments?** Ask the same clinical question in consumer ChatGPT and in a clinician-facing or enterprise healthcare deployment, then compare the sources each one names. Divergence is the finding: a brand present in one and absent in the other has a surface-specific gap rather than a general GEO problem, and the remediation differs accordingly. **Where we appear in AI answers, is the extract on-label?** Read the generated answer the way MLR would read a promotional piece, checking whether the efficacy claim arrived with its associated risk language and whether the indication is stated accurately. An extract that carries the benefit without the boxed warning is a labeling exposure regardless of whether your own page was compliant. **Are our paid programs optimizing toward real high-value actions?** Audit the conversion actions marked primary in GA4 and imported into the bidding platform, and confirm each one maps to a behavior with real commercial meaning such as a treatment center search, a rep request, or a support program enrollment. Scroll depth, video starts, and duplicate locator taps inflate the conversion rate and teach Smart Bidding to buy the wrong traffic. ## The independent layer Same diagnostic shape as any measurement audit. The expensive problems rarely look like problems on a stage. This is not an argument for firing your agency. It is an argument for one scorecard your agency does not own: whether the brand is present in the answers patients and clinicians actually read, whether that presence is accurate, and whether the dollars chasing those audiences point at outcomes that mean something. Presence in AI answers is being allocated right now, query by query, while most brand teams still report rankings and impressions. The teams that treat the answer layer as a channel this year, scored rather than sloganeered, will be very hard to displace from it later. I was not in the room. The scorecard matters more than the room. --- # A Prompt for Deflating AI Vendor Claims URL: https://benzipkin.com/writing/vendor-claim-deflator Date: 2026-09-02 Tags: martech, prompts Every AI martech pitch this year sounds roughly the same. Something is agentic. Something is proprietary. Something eliminates a workflow you were told two years ago to invest in. The demo is smooth because the demo is built to be smooth. The problem is not that vendors exaggerate. It is that pitch language is engineered to make certain questions feel rude to ask. "How does that work with our consent framework" lands like skepticism when it is really just diligence. So delegate the rudeness. Paste the pitch into this and let the machine ask. ## The Prompt ``` You are a skeptical buyer-side evaluator of marketing technology. You have sat through hundreds of vendor demos and you have been wrong before, so you are rigorous rather than cynical. Your job is not to reject the product. Your job is to make the next conversation with this vendor impossible to fake. Context: - Vendor and product: [VENDOR / PRODUCT] - What they say it solves: [PROBLEM] - Where it would sit in our stack: [SYSTEMS IT WOULD TOUCH] - Regulatory context: [MLR / OPDP / HIPAA / GDPR / NONE] - Pitch language, verbatim: [PASTE THE DECK COPY, WEBSITE COPY, OR EMAIL] Work through this in order. 1. CLAIM EXTRACTION. Pull every distinct claim out of the pitch. Strip the adjectives and restate each one as a flat, testable sentence. Sort them into three buckets: capability claims (the product does X), outcome claims (you will get Y), and category claims (we are the first, the only, the leading). 2. CLAIM CLASSIFICATION. For each capability claim, decide what it actually is: a shipped product feature, work performed by humans at the vendor, a roadmap item described in the present tense, or a property of the underlying data rather than the software. Vendors blur these four constantly. Flag any claim you cannot confidently classify from the language given. 3. THE QUESTION THAT BREAKS IT. For each capability claim, write the single question that would expose it if it were untrue. Favor questions that require the vendor to show something rather than answer something. A good question ends with "can you show me that on our data, right now." 4. DATA PROVENANCE AND EXIT. Answer, or flag as unanswerable from the pitch: where does their data come from, who owns the outputs, what happens to our data once it is in, is anything trained on it, and what exactly can we export on the day we leave. 5. REGULATED CONTEXT. Skip this if the regulatory context above is NONE. Otherwise identify what breaks under review: what generates content that would need approval, what touches identifiable data, what would we have to produce in an audit, and what happens when the model output changes between review and publication. 6. THE IRREVERSIBLE PART. Name what is genuinely hard to undo eighteen months in. Not the contract term. The data model, the taxonomy, the retraining, the thing that quietly becomes the system of record. 7. OUTPUT. Give me the five questions worth asking, ranked by how much the answer would change the decision. For each, add one line describing what a real answer sounds like and what an evasive one sounds like. Then, separately, list any claim in the pitch that is probably true and genuinely useful, so I do not walk in having talked myself out of something good. ``` ## How to read the output Step 2 is where most of the value is. The gap between a shipped feature and a human doing the work at the vendor is the gap between a product that scales with you and a services retainer with a login screen. That distinction almost never survives contact with a deck, and it is the single thing most likely to determine whether the tool still works when you triple the volume. Step 7 exists so this stays honest. A prompt that only produces objections is its own kind of bias, and plenty of these tools are good. The goal is a fair fight, not a takedown. One habit worth keeping: run this before the demo, not after. Afterward you are arguing with something you already watched work. --- # The NPI Registry connector is reference data, not targeting URL: https://benzipkin.com/writing/npi-registry-connector-pharma-marketing Date: 2026-08-24 Tags: analytics, measurement Anthropic shipped an [NPI Registry connector for Claude](https://academy.claude.com/tutorials/using-the-npi-registry-connector-in-claude), giving the model direct access to the CMS NPPES registry: validate an NPI, pull a full provider record, or search millions of providers by name, specialty, and geography. The tutorial suggests Medical Affairs use it to identify key opinion leaders. That is the framing most pharma marketers will latch onto, and it is the one thing the connector cannot support. I ran it against real brand team questions. Five findings, all reproducible in about ten minutes. **Default address behavior corrupts geographic queries.** A search for medical oncologists in Madison, Wisconsin returned providers practicing in Dallas, Augusta, and Minneapolis, because the default matches mailing addresses too. Roughly 15% of results were wrong. Setting `address_purpose=PRIMARY` removed every false positive. **Specialty search matches hidden taxonomies.** Providers register up to fifteen taxonomy codes and search matches all of them, but results return only the primary. My oncology search surfaced a neuro-oncologist listed as Neurology. Filter on the returned field and you drop relevant physicians. Count raw results and you inflate the universe. **Brand names are not legal entity names.** A regional health system search returned three affiliates operating under entirely different names, and the parent authority held four separate pharmacy NPIs within ten results. NPI count is not site count or account count. **The data is unverified.** In a handful of queries: a hospital name misspelled in its own record, a phone number of `000-000-0000`, an active provider last updated in 2022. CMS does not validate what providers submit. **You cannot size a market.** The API returns no reliable total and pagination caps at 1,200 records. You can enumerate a metro, not a country. ## The compliance question NPPES is public. Querying it creates no exposure. The join does. NPI is the key that converts anonymous digital behavior into identified prescriber behavior. Your consent architecture and MLR-approved data use language were almost certainly not written to cover that. - **Never pass an NPI into GA4.** It is a direct identifier and Google's terms prohibit sending PII. This is the most likely way the connector gets implemented badly. - **Full records expose DIRECT secure messaging endpoints.** Those are clinical interoperability addresses for exchanging patient information, not a marketing channel. - **NPI is the identifier used in Open Payments.** Systematic tracking of a named prescriber carries perception risk independent of whether it is permissible. The join is a privacy and legal decision, not one the analytics team makes alone. ## Where the value is Upstream of campaign execution, in the reference data layer pharma marketing has historically outsourced and rarely audited. - **Target list hygiene.** `npi_validate` runs a local Luhn check with no API call, catching transposition typos before they cost a match rate or corrupt a report. Least glamorous, highest immediate return. - **Speaker and investigator verification.** Confirm identity, specialty, licensure state, and active enumeration in about fifteen seconds. A first pass ahead of a state board check, not a substitute for one. - **Account entity resolution.** Map brand names to legal entities to NPI sets so ABM account structure reflects how a system is actually enumerated. - **Vendor audience QA.** When a media partner sells you a verified HCP audience, ask for a sample of the NPI list and check specialty and status yourself. You learn something either way. It holds no prescribing volume, no claims data, no verified affiliation, and no measure of clinical influence. Treat it as free, fast, imperfect reference data that improves the quality of everything downstream. The teams that get value here will use it to clean the inputs. The teams that get in trouble will use it to build a targeting list. --- # The enigma of direct traffic URL: https://benzipkin.com/writing/enigma-of-direct-traffic Date: 2026-08-14 Tags: measurement, analytics, ai-search For most of my career I treated direct traffic as a rounding error with a public relations problem. Something to explain away in a footnote and move past before anyone asked a second question. I was wrong about it, and the reason is more interesting than the correction. Every session that arrives at a website gets checked for provenance. A referrer, campaign parameters, a click identifier, a cross-domain handoff. If any of those resolve, the session gets a label. If none do, it lands in direct. So direct is not a description of how someone arrived. It is a record that the system could not tell. Every other row in an analytics report is an assertion. Direct is the only one that is an admission. That sounds like pedantry until you notice which way the number is moving. Digital measurement grew up inside an assumption nobody bothered to state: that attribution converges toward completeness. Every year the tooling improved and the gaps narrowed, which taught a whole discipline to read unattributed traffic as a competence problem. That assumption has quietly stopped being true. Consent frameworks, referrer policies, in-app browsers, and AI assistants are each removing provenance for reasons that have nothing to do with how good anyone is at their job. The unattributable share is growing, and it is the first time the trend has pointed this way. Which creates a second problem I did not appreciate until I had watched it happen in enough rooms. Every channel in a marketing report has an owner with a reasonable interest in their row looking good. Direct has no owner. It is the one line nobody is accountable for, and unowned upside gets claimed by whoever has the strongest incentive. In practice that means a direct surge during a media flight gets attributed to media, confidently, without a test. The asymmetry gives it away: when direct rises during a flight it is proof the campaign is working, and when direct falls during a flight it is a measurement issue. The same number cannot be a result in one direction and an artifact in the other. I do not think much of this is bad faith. Nobody has to be dishonest for a number with no owner to drift toward whoever wants it most. And I have an interest here too, which is worth saying out loud, because being the person who arbitrates whose number it is happens to be good for me. The only defense, for any of us, is to make the claim testable and then run the test. Did branded search move with it. Did the lift concentrate in exposed markets. Those questions have answers, and the answers take an afternoon. Direct traffic is not an enigma because it is mysterious. It is an enigma because it is the one number that admits what the others are hiding. --- *The practical version, including how to decompose a direct bucket and what to report instead: [Direct traffic is not a channel](https://pharmaforward.com/thinking/direct-traffic-not-a-channel/).* --- # Deploying Snitcher Through Matomo Tag Manager URL: https://benzipkin.com/writing/deploying-snitcher-through-matomo-tag-manager Date: 2026-08-02 Tags: analytics, measurement Most of the Snitcher documentation assumes you are running Google Tag Manager. Most of the community write-ups assume the same. If you are on Matomo, you are on your own, and the gaps are not obvious until you are three hours into debugging a data layer that was never going to fire. I recently stood this up on a regulated healthcare property. Here is the version that works, plus the three things that will cost you an afternoon if nobody tells you first. ## The short answer Yes, it deploys through Matomo Tag Manager. There is no native template, so you are writing Custom HTML tags. The architecture is two tags, one custom event, four Data-Layer variables, and four visit-scope custom dimensions in Matomo. The part that is genuinely different from a GTM build is not the loader. It is getting the company data into Matomo at all, because the reverse-IP lookup resolves after your pageview has already fired. ## Trap one: MTM does not read `window.dataLayer` Matomo Tag Manager uses `window._mtm`. If you port a working GTM setup across, your Data-Layer variables will resolve to undefined and you will get no error, no warning, and no indication that anything is wrong. The tags fire. The values are empty. Every push goes to `_mtm`: ```js window._mtm = window._mtm || []; window._mtm.push({ event: 'snitcher_identified', SnitcherCompanyName: c.name, SnitcherCompanyDomain: c.domain, SnitcherCompanyIndustry: c.industry, SnitcherCompanySize: c.size }); ``` Your Custom Event trigger then listens for `snitcher_identified` exactly as it would in GTM. ## Trap two: visit scope, not action scope This is the one that actually matters analytically. Snitcher's identification is a network round trip. By the time it resolves, Matomo has already sent the pageview. If you create your custom dimensions as **action scope**, the company data attaches only to the trailing event you fire afterward, and your entry pageview stays blank. That breaks landing page analysis by company, which for most people is the entire reason they bought the tool. Create the dimensions as **visit scope**. Visit scope backfills across the session, so the company name attaches to the whole visit including the pages that loaded before the lookup finished. Do not solve this by delaying the Matomo pageview until Snitcher resolves. You will lose more sessions to bounce than you gain in attribution, and you will have introduced a third-party dependency into your core analytics load path. Bad trade. ## Trap three: two API shapes in the wild Snitcher's newer Radar loader and the older Spotter snippet return identification data in different shapes, and which one you get depends on the build you are served. The callback path gives you `{ type, company: { name, domain, industry, employee_range } }`. The promise path gives you `{ success, data: { name, domain, industry, size } }`. Rather than betting on one, normalize both and guard against a double push: ```js function normalize(id) { if (!id) return null; if (id.company) { if (id.type === 'isp') return null; return { name: id.company.name, domain: id.company.domain, industry: id.company.industry, size: id.company.employee_range }; } if (id.success && id.data) { if (id.data.type === 'isp') return null; return { name: id.data.name, domain: id.data.domain, industry: id.data.industry, size: id.data.size }; } return null; } ``` Worth noting: `getSpotterIdentification` is not in the loader's stub method list, so it only exists once the real script has initialized. Call it inside `Snitcher.ready()` or it will not be there. ## Writing to Matomo If Matomo is deployed through MTM's own Matomo Analytics tag, you cannot always rely on a `_paq` queue being present. Reach for the tracker instances directly and fall back: ```js function apply(t) { if (name) t.setCustomDimension(5, name); if (domain) t.setCustomDimension(6, domain); if (ind) t.setCustomDimension(7, ind); if (size) t.setCustomDimension(8, size); t.trackEvent('Snitcher', 'Company Identified', name || '(unknown)'); } if (window.Matomo && Matomo.getAsyncTrackers) { Matomo.getAsyncTrackers().forEach(apply); } else { var _paq = window._paq = window._paq || []; _paq.push(['setCustomDimension', 5, name]); _paq.push(['trackEvent', 'Snitcher', 'Company Identified', name]); } ``` Swap the indices for whatever Matomo assigned you. They will not be 5 through 8 unless you got lucky. One cost to be aware of: that trailing event adds a hit to every identified visit, which nudges your actions-per-visit metric. If that number is reported anywhere, either segment the event out or check whether your Matomo version supports a lighter-weight ping. ## The part nobody puts in the setup guide Two defaults deserve a second look before you publish, and both matter more in regulated industries than the docs suggest. **Turn off automatic form tracking.** Radar redacts fields it recognizes as sensitive, which means password and credit card. It does not know what an NPI number is. It does not know that a free-text box on a medical information request form might contain an adverse event narrative. On any site handling clinical or professional identifiers, set `formTracking: false` and instrument the forms you actually want with an explicit allowlist. Letting a third-party processor sweep the DOM is not a decision to make by accepting a default. **Keep the ISP guard.** Discarding identifications where `type === 'isp'` is what keeps residential and mobile carrier lookups out of your dataset. Skip it and you are storing company-shaped noise for every visitor on a home connection, which is both useless and a harder conversation with a privacy reviewer than it needs to be. And set expectations on the identification rate before anyone sees the first report. If your audience is professionals rather than corporate buyers, a real share of your traffic arrives from home and mobile connections that correctly get discarded. The number will look low against a typical B2B benchmark. That is the guard working, not the implementation failing. ## Consent If your CMP gates the tag manager load itself, you do not need an in-container consent trigger, and that is the cleaner pattern. Nothing in the container can fire early regardless of how someone configures a tag next quarter. Two things to verify rather than assume. First, which consent category actually gates the load. If your tag manager loads on a performance or analytics grant, confirm that your privacy team classifies reverse-IP firmographic lookup as sitting inside that category rather than under targeting. That is a one-line email now and a remediation project later. Second, check whether the post-consent load holds across geographies. Plenty of deployments run opt-in for EU and UK traffic but notice-only elsewhere, which means the gate may be doing less work than the architecture diagram implies. Neither blocks the build. Both belong in whatever document describes the implementation, because the answer to "was this consented" should not have to be reconstructed from a container version history eighteen months from now. --- # A Prompt That Tells You Whether Your Analytics Can Be Trusted URL: https://benzipkin.com/writing/analytics-trust-prompt Date: 2026-07-22 Tags: measurement, prompts The reports that cause the most damage are the ones that look finished. Clean chart, plausible number, no error state — so nobody opens the layer underneath. I've written before about [a paid search program reporting a 76% conversion rate](/writing/the-76-percent-error) that turned out to be an artifact of how conversions were counted. The report rendered correctly the entire time. The events feeding it were wrong. That's the shape of most pharma measurement problems. Not a missing dashboard — events that fire twice, parameter names nobody agreed on, and query strings quietly carrying PII into a platform that was never cleared to hold it. This prompt grades the implementation before you make a decision with it. Two things make it more useful than a tagging checklist. It starts from the three decisions the data is supposed to inform, so "we track that" gets tested against "can it actually answer this." And it is deliberately strict on privacy exposure, which in a regulated category is the finding that matters most and gets audited least. ## The prompt Paste it into any frontier model, fill the brackets, and paste whatever artifacts you have. It is told to work only from what you provide and to name gaps instead of inventing them. ``` You are a senior digital analytics engineer who works exclusively on regulated healthcare properties. You know GA4, Google Tag Manager, Matomo, consent frameworks, and the privacy constraints that apply to pharmaceutical and medical device sites in the US and EU. You are reviewing someone else's implementation and your job is to find what is broken, not to be encouraging. Context: - Property: [SITE URL] - Brand / product: [BRAND, or "unbranded disease education"] - Primary audience: [PATIENT / HCP / BOTH, and how they are separated] - Stack: [e.g. GA4 + GTM, Matomo, both] - Markets: [e.g. US only, US + EU] - Consent tooling: [e.g. OneTrust with Google Consent Mode v2, none] - The three decisions this data is supposed to inform: 1. [e.g. "where to shift media spend next quarter"] 2. [...] 3. [...] I will paste some or all of the following. Work only from what I provide. If something you need is missing, name it and say what you would check, rather than assuming it exists. - GTM container export (JSON) - List of GA4 events with parameters - Data layer sample from a key page - Screenshot or export of the events / key events report - The report or dashboard a stakeholder currently looks at Work through this in order. 1. DECISION COVERAGE. For each of the three decisions above, state whether the current implementation can actually answer it. Name the specific event or dimension that would carry the answer. If none exists, say "not measurable today" and describe the minimum instrumentation that would change that. 2. EVENT INTEGRITY. Review the event and tag inventory for: duplicate firing, events triggered on page load that should be interaction based, triggers scoped too broadly (all clicks, all forms), recommended GA4 event names used for non standard purposes, and custom names that collide with reserved ones. Quote the tag or trigger you are flagging. 3. NAMING AND STRUCTURE. Assess whether event and parameter names follow one convention consistently, whether parameters are registered as custom dimensions, and whether the same user action is named differently across pages or properties. Flag anything that will break a year-over-year comparison or a cross-brand roll up. 4. PRIVACY EXPOSURE. This is the section to be strictest on. Identify anywhere PII or health-inferring data could reach the analytics platform: email or member IDs in query strings or page paths, form field values captured by auto-event tracking, URLs that reveal condition or treatment status, ISP or user ID fields, third party pixels firing before consent, and any hashed identifier that is still re-identifiable. For each finding, state the exposure (HIPAA, GDPR, state privacy law, or brand policy), and the fix. Also state which findings warrant escalation to privacy or legal rather than being fixed quietly by the analytics team. 5. CONSENT AND SUPPRESSION. Assess whether tags respect consent state, whether Consent Mode or the Matomo equivalent is configured, and whether any tag fires regardless of choice. Note where consent gaps would make reported volume unreliable and by roughly how much. 6. REPORTING TRUST. For the report a stakeholder currently reads, identify which numbers on it are trustworthy, which are directionally useful but not precise, and which should not be used at all until fixed. Be blunt about the third category. Output: A) Scorecard. Six areas, each rated sound / weak / broken, one line of quoted evidence per rating. B) Findings table: issue, severity (critical / high / medium), what breaks because of it, and the fix. C) Top five fixes ranked by impact against effort, each naming the specific tag, trigger, variable, or page. D) One sentence I can send to a brand lead explaining what this data can and cannot be used for right now. Format for a mixed audience. Three sentence executive summary first, then detail. No generic advice about "implementing best practices." Name the tag, the parameter, the page. ``` ## Reading the results **Section 4 is the one to read first.** Privacy exposure is what turns this from an analytics exercise into something the rest of the organization can act on, because it produces findings in a form a privacy team recognizes: a named exposure, the regulation it touches, and the fix. Note the escalation instruction inside it. Some findings — a member ID sitting in a page path, a pixel firing before consent — are not for the analytics team to quietly clean up. Route those. **Section 1 is the uncomfortable one.** Asking whether the implementation can answer the three decisions it exists to serve is a different question from whether tags are firing. "Not measurable today" on a decision someone is already making is the most useful sentence the audit produces. **Make it quote evidence.** Same caution as the [answer-engine site audit](/writing/site-audit-answer-engine-prompt): a reviewer that paraphrases instead of quoting will happily hand you a passing grade. The prompt demands a quoted tag, trigger, or parameter per rating. Hold it to that, and re-run the section if it goes vague. **It only sees what you paste.** This is a review of configuration, not a crawl. A container export plus the current stakeholder report is usually enough to get the six ratings; less than that and the honest answer is a lot of "name what you would check." Output D — the single sentence explaining what the data can and cannot be used for right now — is the part that travels. Most measurement conversations stall because nobody will say plainly which numbers are safe to act on. That sentence says it. If the audit comes back saying the instrumentation itself is the problem rather than the reporting, that's the rebuild I open-sourced as [ard-to-analytics](/writing/ard-to-analytics) — requirements, container, QA plan, and GA4 checklist generated from one spec, so the drift doesn't quietly return six months later. --- # ard-to-analytics: analytics implementation as code URL: https://benzipkin.com/writing/ard-to-analytics Date: 2026-07-11 Tags: analytics, measurement, open-source Analytics implementations drift. The ARD says one thing, the GTM container does another, and the QA spreadsheet describes a third version that never shipped. Every handoff between documents is a chance for the spec to mutate quietly, and in pharma the mutations carry compliance risk. I released [ard-to-analytics](https://github.com/bzipkin/ard-to-analytics) to fix the handoff problem. It generates five artifacts from a single `spec.json` file, so what the ARD describes is exactly what the container deploys and exactly what the test plan validates. ## What it produces 1. **Technical discovery** from live page analysis — what's firing, what's missing, what's misconfigured. 2. **Analytics Requirements Document** with objectives, KPIs, and event specifications. 3. **GTM container** in importable JSON — no manual tag authoring. 4. **QA test plan** with verification cases tied back to the ARD line items. 5. **GA4 setup checklist** covering custom dimensions, conversions, and audience definitions. All five are generated from the same spec. Change a parameter name in one place and it propagates everywhere. The drift problem becomes structurally impossible. ## Why a single source file matters Manual container builds are slow and error-prone in ways that don't surface until after launch. A tag fires on the wrong trigger. A custom dimension index doesn't match the GA4 property. An event name in the QA sheet doesn't match what's actually deployed. These are ordinary mistakes in an ordinary workflow, and each one burns hours of debugging time. Deterministic generation from `spec.json` means every artifact is consistent by construction, not by careful manual cross-referencing. A validation gate checks for structural issues, unresolved references, and — for pharma and healthcare implementations — PII and PHI exposure before anything ships. ## How to use it The tool works as a Claude skill or as standalone Python scripts. As a skill, you describe what you need in plain language and review outputs at each stage. Standalone, you run the generators directly against your spec file. ``` python scripts/generate_container.py spec.json python scripts/validate.py spec.json python scripts/generate_test_plan.py spec.json ``` Python 3.9+, no heavy dependencies. ## What it's for This grew out of repeated client work — the same implementation workflow, the same categories of mistakes, the same hours spent reconciling documents that should have been generated from a single source. Regulated industries benefit most because the compliance validation is built in, but the consistency problem exists everywhere analytics implementations involve more than one deliverable. The repo is MIT-licensed and [on GitHub](https://github.com/bzipkin/ard-to-analytics). --- # Why my site has a Now page URL: https://benzipkin.com/writing/why-my-site-has-a-now-page Date: 2026-07-03 Tags: aeo, personal-brand Bios are archaeology. Mine tells you I've spent two decades in pharma and biotech, that I founded PharmaForward, that I won an award in 2024. All true. None of it answers the question people actually ask: *what are you working on now?* That question gets asked more than it used to — and increasingly, it gets asked to a machine. Someone types my name into ChatGPT or Perplexity before a call. The engine assembles an answer from whatever evidence it can find. If the freshest thing on my site is a bio that reads the same as it did last year, that's the answer: a man frozen in his own press release. So I added a [Now page](/now). It's an old idea — Derek Sivers started the convention years ago — and the concept is almost embarrassingly simple: one page, a visible *updated* date, and a short list of what I'm actually focused on this month. Right now that's AI-charged dashboards and pulse reports for pharma marketing teams. ## The AEO case I spend my working hours helping pharma brands stay visible and accurately represented in AI-generated answers. The core discipline is always the same: you can't control what the engine says, so you control what it reads. Make the correct answer the easiest one to extract. A Now page is the smallest possible version of that practice, applied to a person instead of a brand: - It answers a **discrete, high-intent question** — "what is Ben Zipkin working on?" — in one extractable block. - It carries a **date**, both visible on the page and as `dateModified` in the structured data, tied to the same Person entity the rest of my site declares. Freshness is a signal; an undated page is evidence of nothing. - It's **listed in my llms.txt**, so a crawler assembling a profile of me finds the current-state answer without digging. None of this is exotic. It's one page and about forty lines of code. That's rather the point: the highest-leverage AEO work is usually structural and boring. ## The human case There's a second reason, and it has nothing to do with machines. A Now page is a forcing function. Writing "here is what I'm focused on" in public means deciding what I'm focused on — and noticing when the list no longer matches the calendar. If updating the page feels embarrassing, the focus drifted. That's useful information at a price of zero. Go look at your own site — or your company's — and ask what it says you're doing *now*. If the honest answer is "nothing since 2023," remember: that's what the machines think too. --- # A Prompt That Audits Your Site Like an Answer Engine URL: https://benzipkin.com/writing/site-audit-answer-engine-prompt Date: 2026-07-03 Tags: aeo, prompts My last prompt audited the *outputs* — what AI assistants actually say about a brand. This one audits the *inputs*: what your site gives the machines to read. Together they're the loop I run for clients: influence the inputs, monitor the outputs. The push for this one came from rebuilding my own site. It had real problems I only found by reading it the way an engine does: a title tag that was literally undefined, two conflicting versions of my identity in the structured data, syndicated articles pointing authority at the wrong domain. The design looked fine. The structure was lying. That's the trap. You review your site by looking at it. An answer engine never sees what you see — it reads source, schema, sitemaps, and dates, then decides whether you're a citable authority or background noise. ## The prompt Paste this into any assistant that can browse (ChatGPT, Claude, Perplexity, Gemini), fill the three brackets, and read the scorecard. ``` You are an answer-engine readability auditor. Audit [SITE URL] the way an AI search engine reads it — structure and evidence only, not visual design. Context: - Site owner: [NAME OR BRAND] - The question this site should be the authoritative answer to: [e.g. "who is Jane Doe", "what does Acme's product treat"] - Industry constraints, if any: [e.g. "regulated healthcare — accuracy and fair balance matter", or "none"] Inspect the following. Report only what you actually find — quote evidence, no vibes. If you cannot fetch something, say "could not verify" rather than guessing. 1. ENTITY. Read the structured data (JSON-LD) on the homepage, the about/bio page, and one content page. Is there exactly ONE Person or Organization entity with a stable @id that other pages reference rather than redefine? Are sameAs links present and pointing at the correct profiles? Are jobTitle and knowsAbout populated, and do they agree across pages? 2. METADATA. Check the title tag, meta description, and canonical URL on the homepage and two content pages. Flag anything undefined, empty, duplicated (like a name suffix applied twice), or self-canonicalizing when the content states it was originally published elsewhere. 3. MACHINE SURFACES. Check /llms.txt, /robots.txt, /sitemap.xml, and whether an RSS feed is declared. Does llms.txt exist and reflect the site's current content? Do sitemap dates vary by page, or does every URL carry one identical build date? Is clean text of key content available (markdown versions, print pages)? 4. FRESHNESS. Find the newest machine-verifiable date on the site — a dated post, a now/updates page, dateModified in schema. State the date and where you found it. 5. EXTRACTABILITY. For the question in my context above: is there one block on this site an engine could lift verbatim as the answer? Quote the best candidate. If nothing qualifies, say "no extractable answer exists" and describe what the block should say. Output: A) Scorecard — the five areas, each rated strong / weak / missing, with one line of quoted evidence per rating. B) Top five fixes, ranked by impact against effort. Name the specific page and describe what "fixed" looks like. C) The one sentence you would expect an AI assistant to say about [NAME OR BRAND] today, based only on what you found. ``` ## Reading the results The scorecard tells you where you stand; part C is the one to sit with. It's the machine's honest summary of you, assembled only from what your site actually provides — not what you meant it to say. If that sentence is out of date, generic, or wrong, the fix list in part B is the path out. Two cautions from running this on real properties. First, make the model show its evidence — an auditor that paraphrases instead of quoting will happily hallucinate a passing grade. The prompt demands quotes for that reason; hold it to that. Second, in regulated categories the fixes still route through review. A schema change is usually low-risk, but anything that touches claims goes to MLR first, same as always. The whole audit takes about three minutes. The last site I ran it on had been "recently redesigned" and scored *missing* on three of five. The design was not the problem. --- # A Prompt for Auditing How Your Brand Shows Up in AI Assistants URL: https://benzipkin.com/writing/pharma-answer-engine-prompt Date: 2026-06-16 Tags: aeo, prompts Your patients and prescribers are already asking AI assistants about their condition before they ever land on your site. Most brands have no idea what those assistants are saying, or whether their own content is even in the room. This prompt turns any frontier model into a diagnostic that shows you how your brand surfaces when someone asks an AI a real clinical question, where competitors and forums are defining you instead, and what to fix first. It's built for regulated healthcare, so every recommendation gets routed through fair-balance and MLR awareness instead of treating your brand like an e-commerce listing. Paste it in, fill the brackets, and you'll have a prioritized action list in about the time it takes to read this paragraph. ## The Prompt ``` You are a generative engine optimization (GEO) and answer engine optimization (AEO) strategist who works exclusively in regulated healthcare. You understand how patients and HCPs actually use AI assistants (ChatGPT, Claude, Gemini, Perplexity, Google AI Overviews) to research conditions, treatments, and brands, and you understand the constraints that FDA fair balance, OPDP, and MLR review place on what a pharmaceutical brand can publish. I'll give you a brand and indication. Your job is to show me how this brand currently shows up, or fails to show up, when its audience asks AI assistants real questions, and what to do about it. Context: - Brand / product: [BRAND] - Indication / condition: [CONDITION] - Primary audience for this exercise: [PATIENT or HCP] - Main competitors or comparators: [COMPETITORS] - Owned properties: [URLs] - Markets: [e.g., US only] Work through this in order: 1. QUESTION LANDSCAPE. Generate the 15-20 questions this audience most plausibly asks an AI assistant about this condition and its treatment options, from early ("what is [condition]") to high intent ("is [brand] covered by insurance," "[brand] vs [competitor] side effects"). Tag each as branded, unbranded, or competitor-framed. 2. LIKELY AI ANSWER. For each question, describe how a current frontier assistant would most likely answer today and which sources it would lean on. Be honest about whether the brand's own content is likely to be cited, ignored, or contradicted. Do not invent clinical facts. Where you are uncertain, say so and tell me what to verify. 3. GAP DIAGNOSIS. Identify where the brand is invisible, underrepresented, or being defined by third parties (competitors, payers, forums, advocacy orgs). Split the gaps into three buckets: content gaps, structured data/schema gaps, and authority/citation gaps. 4. COMPLIANCE-AWARE RECOMMENDATIONS. For each priority gap, give a specific fix. For every recommendation that involves publishing or changing claims, flag whether it needs MLR review, whether it raises fair-balance obligations, and whether it belongs on branded vs unbranded property. Never propose content that states or implies an efficacy or safety claim I have not given you. If a fix requires a claim, tell me what claim is needed and route it to MLR rather than writing it yourself. 5. PRIORITIZED ACTION LIST. Rank the fixes by impact and effort. Tell me the three things to do first and why. Format for a mixed audience: a 3-sentence executive summary a brand lead can read first, then the detail underneath. Be specific. Name the question, the source, the schema type, the page. No generic "create quality content" advice. ``` ## Predicted answers are hypotheses, not evidence Step 2 asks the model what an assistant *would likely* say. That is a fast way to find where your brand is weak — not a record of what any assistant actually returns. Treat every predicted answer as a hypothesis to check, not a citation you can report. To turn it into evidence, run the real queries yourself and log five things for each: the exact query, the engine and model, the date, the verbatim output, and the sources it cited. That measured record is what stands up in a readout; the prediction only tells you where to look first. Note: This is a diagnostic tool. Any output that touches a product claim goes through your MLR process, not the model. --- # The 76% conversion rate that wasn't URL: https://benzipkin.com/writing/the-76-percent-error Date: 2026-06-11 Canonical: https://pharmaforward.com/thinking/the-76-percent-error/ Tags: measurement, paid-search ## The number nobody questioned A patient site's paid search program reported 4,095 clicks and 3,121 conversions over a single period — a 76.21% conversion rate. The monthly reports went unquestioned because they looked like success. Data that flatters does not get audited. Data that disappoints does. That asymmetry let the measurement failure persist for quarters. ## What it actually was No fraud, no single bug. Ordinary configuration decisions compounded: - Engagement events from the analytics layer were promoted to conversion status - Scroll milestones, video starts, and treatment-center locator interactions were all counted as conversions - Some user actions registered through multiple paths, letting a single visit count more than once - A platform migration created tracking gaps that distorted historical comparisons - Automated bidding optimized toward the inflated signal, systematically wasting budget ## The fix was subtraction The rebuild narrowed conversions to native actions tied to real business outcomes: treatment-center searches and doctor discussion-guide downloads. Using a Proxy ROAS framework, the account moved from $1.10 to $2.87 within 90 days. ## Four checks for your own account 1. **Inventory the conversion sources.** List every action counted as a conversion and where it originates. 2. **Check the counting method.** Determine whether actions count once per click or per occurrence. 3. **Sanity-check the denominator.** Conversion rates above 20% on cold traffic warrant investigation. 4. **Audit the value weighting.** Make sure different actions carry proportional algorithmic weight. --- # You can rank #1 on Google and still be invisible in AI search URL: https://benzipkin.com/writing/invisible-in-ai-search Date: 2026-06-10 Canonical: https://pharmaforward.com/thinking/invisible-in-ai-search/ Tags: aeo, geo, pharma-seo Pharma brand teams won the SEO game just in time for the game to move. Here is the process we use to get branded sites cited by AI engines without breaking MLR. ## The click that never happens An oncology brand we work with had the rankings every SEO program chases. Position one on its branded terms, page one on its condition terms, clean technical health. By every traditional measure, the search program was finished. Then we ran the same priority queries through the AI layer. The brand appeared in almost none of the AI-generated answers sitting above its own blue link. The answers were assembled from third-party sources: advocacy sites, reference publishers, a competitor's unbranded content. Priority queries in a recent brand-site audit triggered an AI Overview in 86% of cases. The brand appeared in fewer than 15% of those answers. This is the structural shift. Patients and HCPs increasingly read a synthesized answer before they reach any website, and for a growing share of queries there is no click at all. Search demand did not shrink. It moved upstream of your site, into answers your content either feeds or doesn't. ## Why brand sites lose to answer engines Answer engines cite content that is extractable, structured, and corroborated. A regulated brand site is, by design, none of these. Every sentence has been through claim review, so language is cautious and compound. Definitional content gets pushed off-page to avoid review cycles. Page structure serves navigation and fair balance rather than quotability. The site was built to convert a visitor, never to be quoted by a machine. The standard AEO advice — write fresh conversational answer content — makes the problem worse in pharma. New copy means new MLR review, and the review cycle is measured in months. Teams that follow generic AEO playbooks stall in exactly the place their agency can't help them. ## The process: assemble, don't write The approach that works inverts the playbook. **You do not write AEO content for a regulated brand site. You assemble it from language that has already survived review.** The work is structural, which is why it can move fast inside a compliance environment that otherwise moves slowly. 1. **Inventory the approved language.** The prescribing information, the safety information, the claims matrix, the approved web copy. The operating rule is verbatim: no paraphrasing, no recombining claims into new sentences. If the answer a query deserves doesn't exist in an approved source, that is a content request for the next review cycle, not a copywriting task for today. 2. **Separate audiences structurally.** Patient and clinician assets carry an explicit audience tag through every block of structured data. Clinical depth never migrates into patient-facing assets, and plain-language framing never dilutes the HCP layer. Engines respect this separation when it's machine-readable; reviewers require it. 3. **Build one entity graph, not page-by-page schema.** A single canonical identity for the drug, the condition, and the manufacturer, reused identically across the patient and HCP properties, and connected to the registries engines already trust: DailyMed, ClinicalTrials.gov, FDA. Engines cite entities they can resolve. Most brand sites give them fragments. 4. **Keep fair balance inside the answer.** Every benefit statement in an FAQ or answer block travels with its verbatim safety language, so that an engine lifting the answer lifts the balance with it. An extractable benefit claim without its balance is not an AEO win. It is a compliance incident with distribution. 5. **Validate, then measure citations like a channel.** Structured data is validated against the schema vocabulary and Google's rich-result requirements before anything ships. After launch, a standing query tracker runs the priority set across Google AI Overviews, ChatGPT, Perplexity, Gemini, and Copilot, scored monthly. We call the score the AI Visibility Index, and it gets reported like media performance, because that is what AI search now is. ## What it produced For the oncology brand above, the assembly process took the AI Visibility Index from zero to 82 in 60 days, with the first Google AI Overview citation landing around week five. No new copy was written. Nothing waited on a full MLR cycle, because every string in the structured layer already carried approval. ## What to do this week Two checks, an afternoon of work. Run your priority queries and record how many trigger an AI answer. Then record whether your brand appears in them. If the first number is high and the second is near zero, your gap is structural, and the raw material to close it is already sitting in your approved-content library. Presence in AI answers is being allocated right now, query by query, while most brand teams are still reporting rankings. The teams that treat the answer layer as a channel this year will be very hard to displace from it later.