MMP implementation and migration: Adjust, Branch, Singular

Most measurement stacks I inherit are still running the defaults set during the network's onboarding call: seven-day click, one-day view-through, self-attributing networks ranked above everything else, and cost pulled through the same SDK that reports the conversions. On the last four accounts I took over, that arrangement credited between 19 and 34 percent of installs to a paid source that a geo holdout could not defend. The job here is to rebuild the stack so the numbers survive a conversation with a CFO who does not care which vendor produced them. Where I start: Two weeks reading, not installing. I pull raw install and event exports (Adjust CSV delivery to S3, Branch Data Feeds, Singular's raw export API), rebuild the attribution decisions myself from click and impression timestamps, and set that against the dashboard. The disagreements are the point of the phase. They tell you which windows, which priority order and which reattribution rules are actually doing the work, and which channel has been quietly harvesting organic demand. Implementation: The SDK integration is the smallest part, and your engineers do it from a written spec: initialisation ordering against the consent gate, ATT sequencing, Play Install Referrer on Android, session definition, and the exact place event calls belong. Anything carrying revenue goes server-side, so a patched client cannot mint purchases. What I do myself is the configuration nobody documents. Attribution and reattribution windows argued channel by channel instead of set globally. Click and impression priority. Deduplication against the self-attributing networks that all claim the same install. Cost pulled from each network's cost API rather than the click-level estimate. And server-to-server callbacks writing raw attribution rows into BigQuery or Snowflake, carrying the fields the vendor UI drops. Migration: If this is a move, Branch to Adjust, Adjust to Singular, or off a home-grown tracker, both systems run in parallel for one full billing cycle, both writing to the warehouse, and I write the reconciliation memo explaining the gap. There is always a gap. A migration that reports no delta means one of the two systems is not being read carefully. What I refuse: I will not accept a configuration authored by a network partner. I will not switch on view-through attribution for a channel that has never passed an incrementality test, and I will put that refusal in writing to whoever owns the budget. I will not build a top-line number I cannot reproduce from raw exports in front of you. Not for you if: You are pre-launch with no spend. The questions that matter here only have answers once live traffic is running in at least two paid channels. You want the SDK integrated and nothing more, which any competent contractor will do for a fraction of this fee. Or the answer to whether you would switch off a failing channel is no, in which case the measurement is decoration and I am the wrong person to build it. How we work: Written specs your engineers implement, my review on the pull requests, one weekly call with the person who owns paid. English or Spanish. Spain and Latin America I know from the inside, including install referrer behaviour on the handsets and alternative stores that still carry real volume there. What you keep: The configuration document, the warehouse schema, the reconciliation memo, and a runbook for the four decisions that recur: adding a network, changing a window, disputing a claim, rotating the SDK signature secret.