Contractor‑Ready Mobile Analytics Schema: One‑Page Tracking Plan to Power Experiments & Dashboards

A contractor-ready analytics spec is not documentation plus wishful thinking — it’s a minimal, precise contract. On one page you must define: canonical event names, event descriptions (when they fire), required and optional properties with types, identity strategy, and privacy rules (what is blocked or hashed). This becomes the single source of truth contractors implement and QA against.

Keep the event set focused. Limit to business-critical events (acquisition, activation, core engagement, conversion). Too many events create noise and billing surprises; too few leaves blind spots. Use a stable naming convention (Title Case or snake_case) and never morph the event name to include dynamic values.

Finally, add a conformance checklist: how to validate events (example payloads), where to view them (dev pipeline / staging destination), and a rollback path if bad data appears. Tools and CDPs offer tracking‑plan enforcement; if you don’t have one, require sample payloads and a test matrix from the contractor.

Use a small, consistent vocabulary. Example canonical event names for mobile: Product Viewed, Signup Completed, Trial Started, Subscription Purchased, Feature Used, Experiment Viewed, Experiment Converted. Keep event names stable; properties capture context (screen, variant, plan). Avoid embedding dynamic text or IDs in the event name.

For every event list required properties, their data type, and privacy handling. Example required properties: event_timestamp (string, ISO 8601), platform (string), screen_name (string), user_id (string, nullable), anonymous_id (string). Optional properties include campaign_source, experiment_variant, plan_tier. Mark each property as 'PII — prohibited' or 'safe'.

Provide a short naming convention rule in the spec: Title Case for events, snake_case for property keys, booleans as true/false, numeric IDs prefixed when opaque. That small set of rules prevents the most common implementation drift that breaks experiments and dashboards.

Default to privacy-safe choices so contractors don’t accidentally send sensitive fields to analytics destinations. Declare in the spec that any property flagged as PII must be removed upstream or sent only as a one-way hash. Include rules for IP addresses, device identifiers, and user identifiers (e.g., store user_id in your secure auth system; only send stable user_id once consented).

Add a short list of destinations and whether each destination receives raw events, hashed identifiers, or no PII. If you use a CDP with a tracking plan feature you can enforce these rules programmatically; otherwise make these checks part of code review and a staging validation step.

Finally, require contractors to include a 'privacy smoke test' in their QA: sample payloads showing PII removed, a list of destinations, and a query that shows the latest events in staging to confirm no PII leaked.

Give contractors concrete analysis targets by including sample SQL for typical experiment metrics. Use an events table with canonical columns: event_name, event_timestamp, user_id, anonymous_id, properties (JSON). Example A/B query: compute conversion rate per variant by counting unique user_id where event_name = 'Experiment Converted' within 14 days of 'Experiment Viewed'.

Provide the exact SQL you expect to run against your warehouse. Example (Postgres/BigQuery style): SELECT variant, COUNT(DISTINCT user_id) AS converted, COUNT(DISTINCT CASE WHEN event_name='Experiment Viewed' THEN user_id END) AS viewed, (CAST(converted AS FLOAT)/viewed) AS cr FROM events WHERE experiment_name='purchase_experiment' AND event_timestamp BETWEEN '2025-01-01' AND '2025-01-15' GROUP BY variant;

Also include a 'sanity' query contractors should run after implementation: list recent events, sample payloads, and the top 10 property keys with types. These queries make QA fast and objective.

Supply simple dashboard wireframes to show which charts must work when the contractor finishes: acquisition funnel, activation cohort, experiment variant comparison, and a weekly DAU/MAU trend. For each chart describe the exact query or metric definition (e.g., 'Activation = user completed onboarding_step_count >= 3 within 7 days of signup').

Include a handoff checklist: 1) instrumented events match spec; 2) stage destination shows expected sample payloads; 3) privacy smoke test passed; 4) sample SQL reports produce expected numbers; 5) dashboard panels populate in staging. Make acceptance binary — either each line passes or the contractor resolves it before payment.

A short, mandatory README in the repo or tracking sheet should link to the single‑page spec, include sample curl payloads, and list where to run the verification SQL. This keeps the handoff lean and repeatable across contractors.