Compliance (post #8) is the layer nobody sees. Marketing is the layer that decides whether there's a practice to keep compliant in the first place. This post is about how a solo practice gets found, how the content system is built, how I know which marketing actually produces patients, and why most of the numbers people track in this area are worse than useless.
The framing widens a little here. The earlier posts were about one practice; marketing is the layer where running three brands on a shared architecture actually shows up, because the content systems and the attribution model are built once and reused. So this post talks about the medical ketamine practice, the concierge primary care practice, and the third brand together, where the differences between them are instructive.
Two blog architectures, on purpose
The three brands do not all publish blogs the same way, and the split is deliberate rather than accidental.
Two of the brands publish file-based blogs. A post is a markdown file with frontmatter, committed to the repository under a content directory, and rendered as a static page at build time. Publishing is a git commit and a deploy. The advantage is that the content lives in version control, the posts are diffable and reviewable like code, there's no database dependency for the marketing surface, and the pages are fully static and therefore fast and cheap to serve. The disadvantage is that publishing requires a deploy, which means a non-technical person can't publish without going through the build pipeline, and editing a live post means a commit rather than a form submission.
One brand publishes a database-based blog. Posts live in a database table, are edited through an admin interface, and are rendered at request time with incremental static regeneration. Publishing is a status change on a row; the post appears without a deploy. The advantage is that publishing and editing are immediate and don't require touching the repository, which matters when the content workflow involves quick edits and when the person editing isn't going to run a build. The disadvantage is a database dependency on the marketing surface and a slightly more complex rendering path.
Neither architecture is universally right, and running both taught me when each fits. File-based is right when the content is stable, the authors are comfortable with git, and you want the marketing surface to have zero runtime dependencies. Database-based is right when the content changes frequently, when non-technical editing matters, and when immediate publishing is worth the runtime dependency. The mistake would be to pick one on principle and force it everywhere. I picked per-brand based on how each brand's content actually gets made.
There's a specific operational gotcha the database-based approach introduced that's worth naming, because it cost me real debugging time. A blog listing page that renders from the database at build time will bake in whatever the database returned during the build, and if the build environment can't reach the database (which happens, by design, in some CI configurations), the listing bakes in an empty state and serves it. The fix is to force the listing pages to render dynamically rather than at build time, so they always reflect the live database. It's the kind of bug that looks like "the blog is empty" and is actually "the build couldn't see the database and cached the empty result."
The weekly cadence and the keyword gap
The content engine runs on a weekly cadence. One substantive post per brand per week, give or take, chosen not at random but to fill a specific gap.
The gap-finding method is the part worth describing. Google Search Console reports, for any site, the queries people typed that caused your pages to appear, along with how many times they appeared (impressions), how often they were clicked, and the average position. The useful signal is the query that generates real impressions but few clicks and sits at a mediocre position: it means people are searching for that thing, Google thinks your site is somewhat relevant, and you're not yet winning the click. That's a keyword gap, and it's a content opportunity that the data handed you.
The method is: pull the queries with meaningful impressions, low clicks, and a position outside the top few results, filter to the ones you don't already have a dedicated page for, and write the page that directly answers that query. You're not guessing at what to write. You're reading, from the search data, what people in your market are already looking for and not finding well on your site, and then supplying it. Over months this compounds, because each gap you fill is a page that starts accruing its own impressions and surfacing its own adjacent gaps.
This is unglamorous and it works. It's the opposite of the "write what you're passionate about" content advice, which produces posts nobody searches for. The search data is a list of demand. Filling the highest-demand unmet gaps first is just following the demand.
Attribution that works at this scale
Every marketing conversation eventually reaches attribution: which marketing produced this patient. Most of the sophisticated answers to that question are wrong at solo-practice scale, and the simple answer is right.
The attribution I actually use is last-touch, captured at the moment a prospect first identifies themselves. When someone submits the eligibility form (post #4), the application records two things alongside their submission: the referring URL that sent them to the site, and the landing page they first arrived on. Those two fields answer almost every attribution question I actually ask. The referrer tells me the channel (organic search, a specific referring site, direct, an AI assistant). The landing page tells me which piece of content or which city page did the work of getting them in the door.
For the campaigns where I want more resolution, there's UTM tagging: a link with campaign parameters that get captured into the submission record, so a specific outreach or a specific placement can be measured discretely. And there's a marketing-touch record that logs the sequence of touches for prospects who interact more than once before converting. But the honest truth is that the referrer-plus-landing-page pair carries the overwhelming majority of the signal, and the fancier instrumentation is there for the occasional question that the simple pair can't answer.
The reason not to build multi-touch attribution as the default, covered back in post #3, holds up here: at solo-practice volume, you can't attribute reliably across many touchpoints because the sample per path is too small, and the decisions you'd make differently based on multi-touch data are decisions you're not actually going to make. Last-touch captured cleanly beats multi-touch captured noisily. Build the simple thing well.
Cross-referencing search data with actual analytics
Search Console tells you what happened in Google's search results. It does not tell you what happened on your site after the click. For that you need site analytics, and the two together tell a story neither tells alone.
The cross-reference that matters: Search Console says a page gets a certain number of clicks for certain queries; analytics says what those visitors did after landing (did they read, did they bounce, did they reach the eligibility form). A page with strong search clicks and terrible on-site engagement is ranking for a query it doesn't actually satisfy, which is a content problem the search data alone would never reveal. A page with weak search clicks but excellent engagement is a page that converts the few visitors it gets and deserves more search visibility, which is a promotion opportunity the analytics alone would never reveal.
I check both, on a cadence, for the pages that matter. The failure mode I'm guarding against is optimizing one number in isolation: chasing search impressions for a page that doesn't convert, or celebrating on-site engagement for a page nobody finds. The pages that deserve investment are the ones where search demand and on-site performance both point the same direction. The cross-reference is how you find them.
AI search is already in the data
Something new has shown up in the search data over the past several months, and it's worth flagging because most marketing dashboards aren't built to see it.
A meaningful and growing share of the queries appearing in Search Console are not queries a human typed. They're the sub-questions that AI assistants generate when someone asks them to research a topic. You can recognize them by their shape: full natural-language sentences, oddly specific, phrased as a research prompt rather than a search ("which providers in this category in this city are considered most trustworthy," "list providers with a clear position on price"). These come from AI systems decomposing a user's request into search queries, and your pages appear in the results the AI reads.
The behavior around these is different from human search. The AI reads the snippet and synthesizes an answer; it usually doesn't click through, so these queries generate impressions with almost no clicks. By a click-through-rate metric they look like failures. They're not failures. Being in the top handful of results for the sub-questions an AI generates means your content is part of the source material the AI uses to answer the human's actual question. The exposure is real even though it's invisible to a clicks-based measure.
I don't have this fully figured out, and I don't think anyone does yet. But two things seem right already. First, content that directly and plainly answers a specific question is what AI systems surface, which is the same content strategy that works for human search, so the keyword-gap method above serves both. Second, impressions are becoming a more important metric relative to clicks as AI-mediated search grows, because impression-without-click is exactly the signature of being cited by an AI that answered without sending a visitor. Watching impressions on the AI-shaped queries is the closest thing I have to measuring AI-search presence, and it's a number I've started paying attention to.
Outcomes, not vanity
The heading of this post is the whole point of it. Almost every marketing metric that's easy to measure is a vanity metric, and the ones that matter are harder to get and less flattering.
Vanity metrics are the ones that go up and feel good and don't predict anything: total pageviews, social followers, raw impression counts, time on site averaged across a whole site. They're easy to collect, they trend upward if you do anything at all, and optimizing them doesn't reliably produce patients. The tell is that you can't draw a line from the metric to a patient who booked a visit.
The outcome metrics are the ones that connect to the actual business: how many eligibility submissions came in, how many of those converted to booked first visits, which landing pages produced the submissions that converted (not just the submissions), and the cost and effort per patient acquired through each channel. These are harder to measure because they require connecting the marketing surface to the patient pipeline (post #4) and following a prospect all the way from first touch to first visit. But they're the only numbers that answer the question marketing is actually for: is this producing patients, and which parts of it are producing the most.
The bridge between the two is the same attribution plumbing described above. Because the referrer and landing page are captured on the eligibility submission, and because the submission is linked through the pipeline to whether the person became a patient, I can answer "which content produces patients" and not just "which content produces traffic." That linkage is the whole game. Traffic that doesn't convert is a vanity metric wearing a business-metric costume; conversion traced back to its source is the real thing.
The engagement tier
One more piece connects marketing to retention, because acquiring a patient is only half the economics; keeping them is the other half.
The application scores each patient into an engagement tier based on their pattern of interaction: how recently they've been seen, whether they're keeping to their treatment cadence, whether they're responding to outreach, whether they're showing the signals that precede lapsing. The tier isn't a clinical judgment; it's an operational one, about who's at risk of falling out of care for non-clinical reasons (the appointment that didn't get rebooked, the refill request that went unanswered, the follow-up that slipped).
The tier drives the retention side of the same automation machinery that drives acquisition. A patient sliding toward the at-risk tier triggers gentler, earlier outreach than a patient who's actively disengaged, the same way the incomplete-onboarding cron (post #7) escalates by stage. The point is to catch the drift while it's still recoverable, because a patient who lapses for a non-clinical reason is a patient the practice failed operationally, not clinically, and that's a failure the system can prevent.
The connection to marketing is that acquisition and retention draw on the same infrastructure and the same honesty about metrics. The vanity version of retention is "patient count," which goes up as long as you acquire faster than you lose. The outcome version is the retention rate and the recoverable-lapse rate, which tell you whether the practice is actually keeping the patients it works to acquire. Measuring the outcome version is what keeps the acquisition engine from quietly filling a leaky bucket.
Next time
The next post is about the admin tools that hold all of this together, and about the governance framework for the AI agents that do a growing share of the work: what admin tooling a solo practice actually needs, how to scope an agent's blast radius, where the human-in-the-loop checkpoints go, and the specific commit-and-review discipline that keeps agent-authored work from becoming the post-#2 disaster again. Marketing is how the practice grows; the admin and governance layer is how one person keeps all of it from becoming unmanageable.