Vibe Code Your
Analytics Setup

Vibe Code Your Analytics Setup

Get clarity before you spend: the four-pillar, consent-first tracking stack that turns a small ad budget into a fast read on your funnel.

You Can't Spend
What You Can't Track

Over the last three stretches of this series, the strategy moved into the repo (Growth in Code), then the content story (The Content Skill), then the funnel itself (Vibe Code Your Marketing Funnel). The funnel is built. It can take traffic. And here's where I am as a founder: I don't have the patience to wait for organic to slowly tell me whether any of it works. I want to put a little money behind it – a couple hundred euros – and learn fast.

But spending on traffic before you can measure it is the quickest way to waste both the money and the time. You get a number that went up, a number that went down, and no idea which of your decisions caused either. So before the first euro, you build the instrument.

Spend blind
Money out, noise back
  • ✗ A number with no cause attached
  • ✗ Months to learn what went wrong
  • ✗ Pixels bolted on later, often illegally
  • ✗ Numbers you rent and never fully trust
Spend instrumented
Money out, a lesson back
  • ✓ Every signup traced to its ad
  • ✓ A clear read within days, not months
  • ✓ Consent handled before anything fires
  • ✓ One true number in your own database

This is the part of the Growth Codex I think of as the advanced half. The first levels – strategy, story, funnel – everyone should do. Analytics, traffic and conversion optimisation are the move you make once you actually start investing in traffic. Do them too early and it's premature. Skip them once you're spending and you bleed money you can't account for.

I've run this play before. In a previous mobile-app business we validated ideas with landing pages and paid ads that fed a customer-development survey and a waiting list. We tested the value propositions and the critical hypotheses upfront, with a budget that grew through a couple of levels, starting at €100 – then compared the results across all the app ideas we had in mind and only pursued the ones with the strongest feedback. Paid traffic wasn't the goal. It was the fastest way to be told the truth.

And it told the truth this time too. When we first drove traffic to Bridesmaid's lead magnet, only one to two percent of visitors converted to a trial. I normally expect ten times that. The creative was pulling clicks, the landing page looked right to me – and the magnet still didn't land. That single number sent me straight into an A/B test on the page, and I had a read on the fix within 48 hours. That speed – that's what the instrument buys you. The rest of this is how it's built.

Gate, Measure,
Optimize, Record

The whole instrument is four pillars, stacked from the legal gate at the top to the permanent record at the bottom. None of them is exotic. What's new is that, because the funnel and the product now share one codebase, one agent can wire all four in a single sitting – and you end up understanding the shape well enough to trust it.

Gate
Consent (iubenda)

Asks every visitor, records the answer, and lets the rest of the code branch on it – Measurement and Marketing as independent switches.

Measure
Behaviour (PostHog)

Pageviews, funnels and session replay – how people actually move through the page before they decide.

Optimize

Tells the ad platform which clicks became signups so its algorithm can find more people like them. Add TikTok, Google or LinkedIn the same way.

Record
First-party attribution (your database)

A few columns on your own user record, written once at signup. Consent-free because it's first-party, and the one source you fully own.

For me the four pillars are just natural. Our business home is Germany, so GDPR means a consent gate is a given, not a choice. You need one web-analytics tool – that used to be Google Analytics for me, today I prefer something more modern like PostHog. You need conversion tracking for every ad platform you run, or the algorithm is flying blind. And the fourth pillar, the database, came out of building my first SaaS, CaptAIn – the codebase that became pirateskills.com. For the first time I had a shot at extremely reliable attribution built on my own data and my own cookies, a fixed reference point I can hold Meta's numbers up against.

Which is the mental model worth keeping: the database is what actually happened, PostHog is how they behaved, and Meta is what the ad platform needs to optimise. The three will never show the same number, and that's correct – the database is the one that settles it. The Growth Codex walks the same four steps in its data analytics chapter, including the database as a tracking method in its own right.

Build It Pillar
by Pillar

The running example is Bridesmaid, the wedding-planning startup I'm building – and the funnel all of this measures is live, so you can walk it yourself at bridesmaid.love/tools/first-week.

I built the whole thing in one flowing session with Claude Code on Opus 4.8, in this order: consent first, then PostHog and Meta, then the database. The order barely matters – it just made sense to me to put the legal gate in before anything that fires. The agent wrote the documentation for each part as it went, so future sessions still have the full context. I never wrote a line of it by hand. I talk to the agent.

What follows is each pillar in plain language, with the prompt I used. Paste them into your own agent, in order, adapting the domain names – and put every real key and ID in environment variables, never in code.

Pillar A · The Consent Gate

Under EU and German law you can't drop tracking cookies or fire ad pixels without permission. The banner asks, records the answer, and – the clean part – broadcasts the decision as an event the rest of your code listens for.

The iubenda cookie consent banner live on the site, with per-purpose Measurement and Marketing toggles

Nothing else loads until this gate exists. That one rule – ask first, then branch on the answer – is what keeps every pillar below it compliant by default.

Help me set up a cookie consent banner for my web app, and walk me through it step by step. First ask which framework, language and hosting I'm on so your guidance fits my stack. Then take me through adding iubenda's Cookie Solution: rendering the banner before the page hydrates so it appears instantly, turning on per-purpose consent with Measurement and Marketing as two independent switches, and wiring its callbacks so that whenever consent is read or changed it broadcasts a simple browser event the rest of my app can listen to. Explain why each step matters, tell me exactly where to find my iubenda site ID and help me put it in an environment variable instead of the code, and pause for me to confirm before each change. Don't add any analytics or ad pixels yet, just the banner and the consent event.

Pillar B · Behaviour, Compliantly

This is the one genuinely clever, genuinely compliant idea in the whole setup. Consent gates storage, not capture. PostHog keeps measuring in memory while a visitor is undecided – nothing is written to their device – and only upgrades to stored cookies and session replay once they grant Measurement consent.

The PostHog dashboard Ben built for Bridesmaid – funnel and behaviour metrics for consenting visitors

So you respect the law (no storage without consent) and still see overall funnel health. I run a cookieless version as a comparison point – it even tells me my consent rate – but the deep work happens on consenting users, where I get returning visitors, stitched sessions, and replays I can actually watch.

Help me add PostHog product analytics the compliant way, one step at a time. Start by asking about my stack and where my users are, and recommend the EU (Frankfurt) cloud if I have EU users, since the region can't be changed later. Then walk me through the cookie-banner pattern where capture is always on but storage is what consent gates: initialise PostHog in memory-only mode by default, and only upgrade it to stored cookies and session replay once the visitor grants the 'Measurement' consent from the events we set up in the last step. Help me route analytics requests through a same-origin path on my own domain (a reverse proxy) so ad-blockers don't drop them, and tag every event with the visitor's consent choice. Show me where to put my PostHog keys as environment variables, explain each decision, and check with me before you change anything.

Pillar C · Let the Ad Platform Optimise

Browser pixels get blocked, lost to privacy browsers, dropped on redirects. So you send the same conversion twice – once from the browser, once from your server – with a shared event ID so Meta de-duplicates them into one.

Events Manager in Meta Ads showing the pixel and Conversions API events with deduplication

Both halves still honour Marketing consent; the server copy is about reliability, not getting around the gate. The detail that makes it actually work: carry the ad click ID from the landing URL all the way to the conversion, or Meta can't credit the click.

Help me set up Meta ad-conversion tracking and guide me through each step. Begin by asking about my stack and confirming my consent banner already works, because all of this must be gated on the 'Marketing' consent. Then take me through it: first the browser Meta Pixel, loaded only after Marketing consent, firing PageView, a ViewContent when someone clicks the signup button, and CompleteRegistration after signup. Then the server-side Conversions API for that same registration, sent with the same event ID as the pixel so Meta de-duplicates them into one conversion. Explain why we send it twice, help me capture and forward the Facebook click ID (from the _fbc cookie, or rebuilt from the fbclid on the landing URL) along with the hashed email, and make sure both the pixel and the server event respect Marketing consent. Help me keep the pixel ID and API token in environment variables, and confirm each step with me.

Pillar D · The Record You Own

Third-party tools are subject to consent, ad-blockers and platform whims. First-party data on your own user, in your own database, is durable and yours – the source of truth you reconcile the others against. The trick that makes it survive the journey: scope the attribution cookie to your root domain so it follows the visitor across subdomains.

Signed upUserutm_sourceutm_mediumutm_campaignutm_content (creative)utm_term (audience)signupSourcefbclid (click ID)
Jun 7, 18:41L. H.igInstagram_StoriesBM | Conversions | ABO | 2026-06-04 | v1BM | Story | Yes-Easy-Part | v1BM | UK | Women | 25-34 | Broad | IG only | v1tools-first-weekPAZXh0bgN…
Jun 6, 22:41H. P.igInstagram_FeedBM | Conversions | ABO | 2026-06-04 | v1BM | Story | Yes-Easy-Part | v1BM | UK | Women | 25-34 | Broad | IG only | v1tools-first-weekPAZXh0bgN…
Jun 6, 15:40J. A.igInstagram_FeedBM | Conversions | ABO | 2026-06-04 | v1BM | Story | Yes-Easy-Part | v1BM | UK | Women | 25-34 | Broad | IG only | v1tools-first-weekPAZXh0bgN…
Jun 5, 05:36S. R.igInstagram_FeedBM | Conversions | ABO | 2026-06-04 | v1BM | Story | Yes-Easy-Part | v1BM | UK | Women | 25-34 | Broad | IG only | v1tools-first-weekPAZXh0bgN…

The last four signups from the campaign, straight from our database (scroll across to see the full record). Names and Facebook click IDs are anonymised; every other field is the live first-party data.

I found this the hard way. Our marketing site and app sit on different subdomains, and I noticed my session recordings arriving in two halves – one up to signup, one after – never stitched into the single journey I wanted. A cookie scoped to the root domain crosses that hop where local storage can't. Honestly, getting a setup this fiddly working would have been a nightmare before AI agents. The shared login and sign-up the product already uses is exactly where the write-once step hooks in.

Help me capture first-party attribution in my own database, walking me through it step by step. Start by asking about my stack, my database, and how my marketing site and app are hosted, especially whether they sit on different subdomains. Then guide me through two pieces. First, on the marketing site: a small script that on each page load reads the utm_source, utm_medium, utm_campaign, utm_term and utm_content tags, the fbclid and gclid, and the referrer, and stores them in a first-party cookie, using first-touch logic (written once within roughly a 30-day window and never overwritten) and scoped to my root domain so it survives the hop from my marketing site to my app. Help me get that cookie scoping right, since it's the part most people miss. Second, in the app: add attribution columns to my user record through a database migration, plus a step that runs once when a new user signs up to read that cookie and fill those columns only if they're still empty. Explain each decision, ask me for whatever you need, and let me review before you change anything.

The real point isn't that you memorise any of this. It's that you understand the shape – four pillars, a consent gate, a cookie that crosses subdomains, a de-duplicated conversion – well enough to direct an agent through it and check it did the right thing. That's the skill.

Three Numbers
Never Match

Once it's running, here's the thing nobody warns you about: the same conversion gets counted three different ways, and the three numbers never match.

Meta

The conversions the ad platform managed to attribute.

PostHog

The conversions its consented analytics actually captured.

Database

The signups you genuinely recorded – the truth.

Consent, ad-blockers and lost pixels mean Meta and PostHog both undercount. Your database doesn't – it's first-party and consent-independent, so it's the conversion truth you reconcile the other two against. Cost per signup is ad spend divided by database signups, sliced by campaign.

But I didn't want to read three dashboards by hand every day. So I did the obvious thing: I had the agent build the report too.

The agent-loop Campaign Review in Claude Code – one table reconciling ad spend, impressions, clicks and trial starts across Meta and the database, with an interpretation and the decisions due

I run that report with Claude Code's /loop – a built-in command that re-runs a prompt on a set interval. I point it at one reconcile prompt and it checks in on its own every day or two: it pulls Meta, PostHog and the database, reconciles them, and hands me back one table – ad spend to impressions to clicks to trial starts – with a written read and the one or two changes worth making. It leans on the skills I've already built; it isn't a separate product, just a repeating prompt doing the job.

Help me set up a recurring report that reconciles my analytics, step by step. First ask which ad platform, analytics tool and database I use, and how I want to run it on a schedule, for example Claude Code's /loop running a saved prompt once or twice a day. Then help me build it so each run pulls my ad spend and conversions from the ad platform, my funnel from my analytics tool, and my signup counts from my own database, reconciles the three, and gives me back one table, from ad spend through impressions, clicks and trial starts, with a short read on what's working and the one or two changes worth making. Set it to treat my database as the source of truth and expect the other two to undercount, and walk me through each part so I understand it well enough to adjust it later.

Look at what that one screen shows. About €118 of spend, 90 clicks, 5,665 impressions across two ad creatives. One angle is converting; the other – 21 clicks, zero signups – is a clear pause signal. And the line that proves the whole point: Meta reports two signups, my database reports four. The sources disagree, exactly as they should, and the database settles it. PostHog wasn't even reachable on that run – which the agent flagged rather than quietly dropping.

Here's the deeper reason this matters. There would have been so much I'd have needed to know upfront to brief all of this to a developer – and that's not realistic, even with a fairly deep understanding of analytics. The truth is you only catch the mistakes while real traffic is flowing. Early on I spotted that the Meta server event was arriving without its browser twin on registration, and fixed it on the spot. You run some tracking, spend for 24 hours, see what actually shows up and what doesn't, and correct – until you genuinely trust the data coming in. That state is rarely reached without both deep understanding and the ability to keep iterating. An agent gives you the second one. The Growth Codex chapters on how we report and what to improve are the framework underneath this loop.

Know the Setup,
Stay in Motion

Here's what I want you to take from this. You need to understand the setup – the four pillars, the consent gate, the cookie that crosses subdomains, the de-duplicated conversion – well enough to direct an agent and check its work. You do not need to know every line of code; tools like Claude Code and Codex handle the implementation. What you do need is to stay in regular motion: every day or two, look at whether the data is still flowing and fix whatever isn't.

That's the whole shape. Gate everything on consent. Measure behaviour compliantly. Let the ad platform optimise on a de-duplicated conversion. Keep the source of truth in your own database, then reconcile the three and act on the gap. Build the instrument before you spend, not after, so your very first euro already teaches you something.

That's the instrument. Next week I'll show you what the first hundred or two of Meta spend actually told us once it was running, and the week after, how the ad-testing setup is built on top of it. The point of this week is that none of those numbers would mean anything without the four pillars underneath them.

Your strategy is in the repo. Your story is in the repo. Your funnel is in the repo. The instrument that tells you whether any of it works belongs there too – built by the same agent, from the same context, and finally giving you the truth fast enough to act on.

Cheers,

Ben

Ready to Go Deeper?

Questions & Answers

Ben Sufiani, The Captain

Ben Sufiani

The Captain

Founder from Cologne with 15 years of startup experience across 9 ventures. After helping thousands master growth marketing, Ben learned vibe coding from scratch and launched CaptAIn within three months. He leads the Vibe Coding Cologne community, blending real founder experience with teaching clarity.