Onboarding is complete only when the customer can prove value.

The SDK is not the outcome.

A mobile measurement implementation succeeds when the customer can answer a business question: which campaign produced this install, signup, and revenue? Installing a package is only one dependency in that answer. Identity joins, event definitions, data quality, testing, and a clear handoff are equally important.

For this exercise I modelled RoveCart, a React Native commerce app. Its first useful outcome is a verified Meta journey from campaign click to install, identified signup, and first purchase.

Work backward from proof.

My first-principles approach is to remove product vocabulary at the start and ask five plain questions: what value should exist, what evidence proves it, which identifiers connect that evidence, where can the path fail, and who owns each failure?

1. 01Customer goal
2. 02Data contract
3. 03Identity join
4. 04Validation
5. 05Handoff

The demo mirrors that sequence. It captures campaign context, stores lr_install_id, joins the signup to the install, validates numeric revenue, and keeps the accepted event stream available as evidence.

What is working end to end.

Browser demo
  → POST /api/events
  → linkrunner-key check
  → payload validation
  → Cloudflare D1 storage
  → accepted event stream

Identity path
  campaign_id → lr_install_id → user_id → purchase event

• Real server route: the interface calls a deployed API rather than changing UI state alone.
• Request checks: the server rejects a bad key, missing identifiers, unsupported events, and non-numeric revenue.
• Durable evidence: accepted events are written to D1 and reloaded for the same browser session.
• Ordered journey: later steps remain locked until the prerequisite event passes.
• Honest scope: synthetic data is clearly labelled and no customer or production credential is used.

What a live onboarding still requires.

The demo proves the integration logic, but a real onboarding contains manual work across the customer's app, Linkrunner workspace, device, campaign network, and downstream systems. I would run it as follows.

1. Agree on the success condition

1. Choose one acquisition journey and one business event that proves first value.
2. Name the customer's mobile, data, and marketing owners plus my escalation owner.
3. Write the event contract: names, required fields, identity keys, deduplication IDs, currency, and acceptable latency.

2. Prepare the Linkrunner project

1. Create or select the project and copy its project token.
2. Generate a server key under Settings → Data APIs and store it as a secret, never in the client app.
3. Configure the tracking domain or subdomain and verify DNS ownership.
4. Create the test campaign and tracking link with the intended network and campaign metadata.

3. Instrument the customer app

1. Install the correct SDK for the app framework and initialize it early in the app lifecycle.
2. Call signup when the anonymous installation becomes a known customer.
3. Configure deep links and platform settings for both iOS and Android.
4. Send a small event taxonomy. Revenue must be numeric; every retried event needs a stable unique event ID.
5. Keep personally identifiable information to the minimum the agreed use case needs.

4. Configure data export

1. Expose a public HTTPS webhook endpoint that returns a direct 2xx response and does not redirect.
2. Add it under Settings → Data Export → Webhooks and use the test action before a device run.
3. Authenticate the request, log the delivery, make processing idempotent, and join install and signup with lr_install_id.
4. Alert on repeated failures and account for Linkrunner's webhook retry behaviour.

5. Run the physical-device test

1. Register a real test device in the SDK Console.
2. Remove the app, click the new tracking link, install or open the app within the documented three-minute window, and complete signup.
3. Trigger the agreed first value event, then compare SDK Console logs, webhooks, Linkrunner reporting, and the customer's downstream system.
4. Repeat once with a deliberately invalid field so the team sees the failure and recovery path.

6. Launch and hand over

1. Save payload examples and screenshots as acceptance evidence.
2. Document owners, dashboards, alert thresholds, replay or backfill steps, and escalation contacts.
3. Monitor the first production cohort and close only when the customer can independently verify the result.

References used for this runbook: Linkrunner's official quickstart, integration testing guide, webhook guide, and event capture API.

Define “done” before integration starts.

• A registered device completes click → install → signup inside the test window.
• The install and signup share the same lr_install_id.
• The first purchase reaches Linkrunner and the downstream system once, with the same user, amount, currency, and event ID.
• The dashboard attributes the journey to the intended campaign and network.
• The customer has a tested failure path, named owners, and a written runbook.
• Time from the first test click to verified value is under ten minutes once prerequisites are ready.

What I have not done.

I have not onboarded a live Linkrunner customer. This project does not have a production project token, server key, real customer data, a physical app installation, or access to a customer's ad network and CRM. It is a spec-shaped simulation built from the public product documentation, with a real receiver, validation path, and database.

Those limits are exactly where I would start a paid trial: one real customer or internal test app, one acquisition journey, one measurable event, and an explicit owner on both sides.

What I can own in the first 48 hours.

1. Hours 0–4: map the journey, data contract, owners, risks, and definition of done.
2. Hours 4–16: instrument or audit the SDK, API, webhook, and event mappings.
3. Hours 16–28: run the physical-device test, inspect payloads, and fix the first failure.
4. Hours 28–40: verify Linkrunner reporting against the customer's downstream truth.
5. Hours 40–48: deliver the evidence, runbook, open risks, and next launch decision.

I like ownership because it makes the result unambiguous: understand the problem, build the smallest path that proves it, communicate what is still unknown, and stay until another person can run the system.