Turn your customer data into something the ad platforms can use
First-party data isn't a product you buy — it's a set of decisions about what you collect, where it lives, and what you're allowed to do with it. Most businesses already hold everything they need and can't act on it, because there's no single identifier joining the systems and the hashing is wrong in ways that fail silently. We build the identity spine, fix the hashing, and activate it where it changes delivery.
Free30 minutesNo obligation
First-party data · what breaks
The state we usually find — First-party data
- 01
No single customer identifier
Several partial views of the same person and no way to join them.
- 02
Click IDs never captured
The cheapest, highest-leverage field, missing more often than not.
- 03
Hashing wrong in silent ways
Double-hashed or unnormalised values match nothing and error nowhere.
- 04
Deletion requests that stop at your database
A compliance gap nobody has tested.
First-party data · the fix
What you get out of it — First-party data
One query returns a customer
Identifiers, orders, consent state and originating click.
Match quality that lifts delivery
Enhanced Conversions and CAPI both fed properly.
Suppression that works
Opt-outs propagating to every destination.
Collection you can justify
Fields that have a use, and no others.
First-party data · architecture
Why the numbers were wrong before you got here — First-party data
Worth understanding before buying anything, because it decides which tier you need — and for some readers the answer is that you don't need us yet.
- 1
The browser is the weakest link, and it is getting weaker on purpose
Every browser-side tag has to survive the page loading, the visitor staying, the script running and the request leaving. All four are now contested. The order in your database is certain; the browser event reporting it is not.
- 2
Safari caps the cookie your attribution depends on
Intelligent Tracking Prevention limits JavaScript-set cookies to seven days whatever expiry you set, so a customer who takes longer than a week to decide returns as a stranger. A cookie your own server writes in an HTTP response is not capped — the single largest practical difference between browser-side and first-party server-side.
- 3
Ad blockers remove the tag with no error
A blocked pixel does not warn anyone. The customer buys, the order lands, and no platform hears about it. First-party events from your own subdomain are not a third-party request and are not filtered the same way.
- 4
Consent is enforced by hope, not by architecture
Client-side consent means trusting each vendor script to honour a flag. A server container decides at the container: a denied destination receives nothing. That is a materially stronger position, and it also stops the over-blocking that discards data no law required losing.
- 5
Checkout can end where your tag isn't
Wallets and hosted payment pages can be abandoned after the money moves. Sending the purchase from the order record means it arrives whether or not anyone came back.
First-party data · diagnose
How we scope first-party data activation
Before quoting. Each step narrows what the work actually is, so the price reflects your account rather than an average.
- 01
Can you produce one row per customer?
The question that determines whether anything else is possible.
- 02
Check whether click IDs are captured and stored
Cheapest high-leverage item on the list.
- 03
Map where customer data already leaves for
The list is always longer than expected.
- 04
Check hashing correctness
Verified by match rates, not by reading the code.
- 05
Test whether a deletion request propagates
Submit one and follow it.
- 06
Identify collected-but-unused fields
Exposure with no offsetting return.
First-party data · prove
How the work gets proven — First-party data
A dashboard turning green proves a dashboard turned green. These are what we hand over instead.
Source of truth
Your own customer database or warehouse
- One query returning a customer's identifiers, orders, consent state and originating click.
- Click IDs captured at first touch and stored against the customer record.
- Hashing verified correct by match rates in the platforms, not by inspecting code.
- Enhanced Conversions and CAPI match quality improved against a documented baseline.
- A deletion request traced end to end through every destination.
- Reconciled over a fully closed window, matched on ID rather than on totals — totals hide equal and opposite errors.
- Payload evidence captured from real transactions, saved to your own records.
- The same reconciliation repeated 30 days later, because a setup that works once and drifts is the harder failure.
First-party data · free audit
What we check in the free audit
- Can you produce one row per customer?
- Check whether click IDs are captured and stored
- Map where customer data already leaves for
- Check hashing correctness
- Test whether a deletion request propagates
- Identify collected-but-unused fields
Checked against
Your own customer database or warehouse
Free30 minutesNo obligation
First-party data · when not to buy
When you shouldn't buy this — First-party data
We would rather say it now than three weeks into an engagement.
- Your conversion tracking isn't correct yet. First-party data strategy on broken events produces confident wrong answers.
- You have a few hundred customers. Manage the relationship directly; the infrastructure will cost more than it returns.
- Nobody will own the data once it exists. An unowned customer database decays into a liability.
- You're looking at a CDP because a vendor suggested it. Most of what a CDP is sold for can be done with a server container and your existing database at a fraction of the cost — establish the need first.
First-party data · what we deliver
What's included in first-party data activation
Identity spine
One stable identifier per customer that every system references.
Click ID capture and storage
At first touch, onto the customer record.
Correct hashing
Lowercased, trimmed, E.164 phone, SHA-256, once.
Server-side activation
Hashed identity to each platform through a container that decides what each receives.
Consent state stored with the record
What each customer agreed to and when, held against them.
Deletion propagation
A request traced through every destination that received a copy.
Written guarantee
95%+ tracking accuracy
Measured against Your own customer database or warehouse. Miss it and we keep working at no cost.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
The correct browser-side build, done properly and verified on a live transaction. Honest about its ceiling: it will not survive Safari's cookie cap, an ad blocker, or a checkout that ends somewhere your tag isn't. If you spend $1K+/month on paid media, start one tier up.
- Correct events, correct parameters, correct values
- Verified on a live transaction, not in preview
- Reconciled against your own order records
- Written handover you keep
1st-party server-side
Recommended$800One-time fee · most popular
The tier that changes the outcome rather than patching it. Your money events stop depending on the browser: they are sent from your order records through a first-party server container on your own subdomain, so iOS, ad blockers, consent banners and interrupted payment redirects can no longer take them away. Built in 2–4 days. You own the stack outright, with no monthly SaaS.
- First-party server container on your own subdomain
- Money events sent from your order records, not the browser
- Meta, Google, TikTok, Microsoft and LinkedIn all fed server-side
- Deduplicated on a shared event ID, verified at every destination
- First-party cookies beyond Safari's 7-day cap on JavaScript-set cookies
- 95%+ conversion accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid-media channel server-side, plus the offline loop that connects closed revenue back to the click. For advertisers whose spend makes an attribution leak more expensive than the build.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop, so closed revenue reaches bidding
- Refunds and cancellations reversed at every destination
- Klaviyo identity stitching, BigQuery and Looker Studio
- Monitoring, so the next break surfaces in days rather than a quarter
FAQ
First-party data questions, answered
Usually not. Most of what a CDP is sold for can be done with a server container and the database you already have. Establish the specific need before buying the category.
Capturing click IDs onto the customer record. It's cheap, it's usually missing, and nothing downstream works without it.
By match rates in the platforms, not by reading the code. A double-hashed value looks perfectly valid and matches nothing.
Partly. Storing consent with the record and testing deletion propagation are the parts regulators ask about, and they're the parts most strategies skip.
WhatsApp