Embedded Ad Ops: Conversion Plumbing Your Team Keeps

The finding in week one is nearly always that your platforms and your revenue system disagree by somewhere between fifteen and forty percent, and that nobody has reconciled the two since the last replatform. I do not fix that with a dashboard. I fix it in the pipeline, then leave you the repository and the documentation so the fix survives my departure. Where I am embedded: In your engineering process rather than your marketing meeting. I work in your repository, open pull requests your engineers review, and follow your deploy process rather than a parallel one. I attend the sprint ceremony, not the growth standup. Marketing tells me which decisions the data has to support; engineering tells me what they are prepared to maintain after I go; those two constraints define what gets built. What the work usually is: Server-side tagging on your own infrastructure, a container on Cloud Run or its equivalent behind your own subdomain rather than a vendor's hosted endpoint. Meta Conversions API with event_id deduplication verified in Events Manager rather than assumed from the documentation. Google Enhanced Conversions and Consent Mode v2 wired so consent state is real rather than defaulted to whatever keeps the numbers high. GA4 configured against a written event schema, with the BigQuery export on, which is the point at which reconciliation becomes possible at all. Offline conversion import from your CRM: Salesforce, HubSpot, or kintone if you are a Japanese company, as many of my clients are. For apps: AppsFlyer or Adjust server-to-server events, a SKAdNetwork conversion value schema mapped to something you actually make decisions on, and Aggregated Event Measurement priorities set deliberately instead of alphabetically. For retail feeds: Merchant Center rules, and in Japan, JAN codes handled properly so the feed is not silently disapproved on a Friday. The Japanese part: APPI is not GDPR. A consent banner copied from a European site is simultaneously over-restrictive and non-compliant, in different places. Where a client sells into both regions I build one consent model with two behaviours rather than two tag setups, because two setups drift within a quarter and nobody notices until a campaign underdelivers. How long it takes: A single-platform repair runs two to three weeks. A rebuild across web and app runs six to ten. The constraint on that timeline is your engineers' review capacity, not my hours, which is why I ask about their sprint commitments before quoting. What you keep: A measurement specification naming every event, its parameters, its owner and the decision it exists to support. The repository, in your organisation, not mine. A reconciliation query you run monthly against your own revenue data. And a written note of what I did not build and why, so the next person does not rediscover the same dead ends. If your team cannot operate it after I leave, I have failed regardless of whether data is flowing. Not included: Warehouse modelling, dbt work and BI development. I stop where the data lands correctly and is documented; turning it into the company reporting layer is a different discipline and a different hire. I do not build dashboards as a deliverable. I do not manage ad accounts or make budget decisions. I do not write your privacy policy: I will give your counsel an exact map of what data moves where, and they write it. Not for you if: You want a tracking audit document. Audits are cheap, and this is a build. Your engineering team will not review or merge pull requests from outside, in which case nothing I do survives the next deploy. Or you are hoping attribution will settle an internal argument about which team gets credit for a customer. Measurement does not resolve a political question, and I will decline the brief rather than pretend it does.