First-Party Onboarding, Matching and Consent Lineage

A customer file of Indian users matched on hashed email lands between 20 and 35 percent inside DV360 Customer Match. The same file matched on normalised mobile numbers usually lands between 55 and 75 percent, because the identifier people actually handed over when they enrolled, booked or asked for a callback was a ten-digit number, not an address they check. Deciding which key to match on, in what order, and proving the result afterwards is most of what this work is. What the engagement opens with: Your raw export, read as it is rather than as it is described to me. How phone numbers were stored: leading zero, 91 prefix, +91, embedded spaces, landlines mixed in with mobiles. How emails were captured: typed by a counsellor on a call, imported from a lead vendor, self-entered at checkout. How many rows are the same human twice under two spellings. Normalisation to E.164 and lowercase-trim before SHA-256 is not a formality; it moves the match rate further than any targeting decision you will take this quarter. Consent, settled before anything is uploaded: Under the DPDP Act and the 2025 rules, an audience you cannot shrink is a liability sitting inside a DSP. Every hashed identifier that goes up carries a row in a lineage table: which consent event authorised it, at what timestamp, for which stated purpose, and which withdrawal removes it. Removal runs on the same schedule as the upload rather than on request. For European and US traffic the same table records the TCF and GPP signal the identifier was collected under. What gets built: Membership managed server-side through the Customer Match API, The Trade Desk first-party upload, or Amazon Marketing Cloud audience creation, depending on where you buy. Interface uploads of spreadsheets are the fallback and not the plan; they expire quietly, cannot be diffed, and six weeks later nobody can say which version is live. Segments are cut by the event that earned them and carry a membership duration argued from the buying cycle, not the platform default. Match is reported per segment and per key, with the failures broken out by cause, so you can see whether a weak segment is a data problem or an audience that was never there. Where a clean room is the only route: Ads Data Hub for Google-side reach and frequency questions, Amazon Marketing Cloud for Amazon, a Snowflake-based room when a publisher or airline partner will not move data any other way. I write the SQL and hand it over. Nothing I report should be unreproducible by your own analyst against your own tables. Not included: Building or replacing your CDP. Selecting a consent platform. Appended third-party attributes of any kind, including demographic enrichment and purchased phone-to-household files. Creative, bidding and pacing stay with your buying team; I build the audience layer and the measurement around it, and I do not touch the media plan. Who this is not for: Advertisers whose first-party file is bought leads wearing a first-party label. Teams looking for a higher match rate by relaxing the consent basis rather than fixing the normalisation. Medtech advertisers hoping to onboard a list segmented by diagnosis or prescription: I will not build that audience, and the refusal is not negotiable at a higher fee. How the work is judged: Addressable reach at your working frequency, per segment, before and after. Match rate is an input to that number and a poor result on its own; a 70 percent match on a segment with no purchase intent is worth less than a 40 percent match on people who abandoned a fee payment last week.