## 1. Mandate, Scope, and Definition of Done This audit exists to determine which step, or steps, of the funnel (Ad click → Landing page → Free trial signup → Onboarding completion → Paid conversion) account for the paid-conversion drop observed over the last 30 days relative to the prior 3-month average, so that the product and growth team can prioritize remediation on the correct step rather than the most visible one. The decision this audit is meant to inform is which step enters the next roadmap cycle as a fix target, and in what order if more than one step is implicated. **Stakeholders:** the funnel owner (the growth/product function maintaining Mixpanel instrumentation across all five steps) owns the funnel being audited; the product/growth lead approves any fix that follows from a confirmed finding; the product and growth team is the report's recipient. **Requirements table** | ID | Requirement | Source | |---|---|---| | R1 | Identify which step(s) of the funnel account for the paid-conversion drop, last 30 days vs. prior 3-month average | Supplied (PRIMARY_CONCERN, TIME_PERIOD) | | R2 | Use Mixpanel per-step conversion data (available for the past year) as the primary data source | Supplied (CONTEXT_AND_CONSTRAINTS) | | R3 | Do not access individual user-level session recordings at any point in this audit | Supplied (hard constraint) | | R4 | Examine exactly these five steps, in this order, without adding or collapsing steps: Ad click → Landing page → Free trial signup → Onboarding completion → Paid conversion | Supplied (FUNNEL_DEFINITION) | | R5 | No step has been pre-identified as the likely cause; the audit must not presuppose which step is at fault | Supplied ("nobody's sure which step is responsible") | | R6 | No external benchmark was supplied; "normal" is defined as the prior 3-month average from the same Mixpanel instance | Gap revealed by inputs | **Explicit exclusions:** channel- or creative-level performance feeding traffic into "ad click" is out of scope unless a confirmed leak later traces there; external industry benchmarks are excluded as a comparison basis, since real internal historical data covering the required window already exists in Mixpanel; individual-level behavioral evidence (session recordings, per-user event traces) is excluded per R3. **Solution shape:** every step conversion rate for both the current and baseline windows is hypothesized pending a real Mixpanel pull (Section 3, A1–A10) — none was supplied as a number. Root causes are hypothesized categories pending the pull identifying which step leaked (Section 6). The analyst running the Mixpanel pull owns closing the data gap; the product/growth lead owns closing the root-cause gap once the leaking step is known. **Completion criteria:** - Mixpanel pull for A1–A10 completed and logged (Section 7, Section 8). - Section 9 data-quality checks run, with pass/fail recorded for every step. - The leaking step(s) identified at Confidence: confirmed, not suspected (Section 4). - At least one root-cause hypothesis for the confirmed leak reaches Confidence: data-supported or confirmed, or is reported as unresolved with a named blocker (Section 6, Section 7). - Every Section 12 row touching stakeholder presentation is resolved to READY FOR HUMAN REVIEW or explicitly declined. A findings deck alone is **not** completion — see Section 13 for the full handoff bar. ## 2. Auditor Instructions ``` Diagnose this funnel against real data for the stated period, not assumed or remembered numbers. Pull current step-by-step conversion data first. Check for a prior audit on this same funnel before re-deriving findings that already exist. Resolve every <VALIDATE> item using a real data pull or real user research — not internal guesswork. Produce actual findings grounded in actual numbers; do not stop at a plausible-sounding narrative. Run the data-quality checks defined in Section 9 before trusting any number in the diagnosis. Stop treating a data-quality issue as a user behavior finding; report a concrete blocker when progress needs data access, tooling, or research outside your authority. Do not present a suspected cause as a confirmed one, invent a conversion rate, or cite a benchmark that wasn't actually checked. Continue safe, low-cost analysis of already-accessible data while a finding-critical validation is pending. Present findings to stakeholders as confirmed, or commission new user research, only within approved authority. Report progress using actual data-pull results, and clearly separate suspected, data-supported, and fully confirmed findings. Operational defaults (which dashboard or query tool, how the report is formatted for stakeholders) may be chosen and documented autonomously. Do not autonomously invent data-pull results or claim research was conducted when it was not. ``` In particular: do not assume which of the five steps — ad click→landing page, landing page→signup, signup→onboarding, or onboarding→paid — is responsible for the conversion drop; that attribution is the central `<VALIDATE>` item this audit exists to resolve, not an audit default. ## 3. Funnel and Data Assumption Ledger **Current per-step conversion rates (last 30 days)** | Assumption ID | Claim | Source | Confidence | Consequence if wrong | |---|---|---|---|---| | A1 | Ad click → Landing page conversion rate, last 30 days | Unverified — `<VALIDATE: rate-ad-landing-current>` | Low (not yet pulled) | Misidentifies or clears the top-of-funnel step incorrectly | | A2 | Landing page → Free trial signup conversion rate, last 30 days | Unverified — `<VALIDATE: rate-landing-signup-current>` | Low | Same | | A3 | Free trial signup → Onboarding completion conversion rate, last 30 days | Unverified — `<VALIDATE: rate-signup-onboarding-current>` | Low | Same | | A4 | Onboarding completion → Paid conversion rate, last 30 days | Unverified — `<VALIDATE: rate-onboarding-paid-current>` | Low | Same | | A5 | Overall Ad click → Paid conversion rate, last 30 days (headline metric) | Unverified — `<VALIDATE: rate-overall-current>` | Low | Misstates the size of the problem this audit was commissioned to explain | **Baseline / "normal" (prior 3-month average, same Mixpanel instance — no external benchmark used, per R6)** | Assumption ID | Claim | Source | Confidence | Consequence if wrong | |---|---|---|---|---| | A6 | Ad click → Landing page conversion rate, prior 3-month average | Unverified — `<VALIDATE: rate-ad-landing-baseline>` | Low | Same as A1, for baseline comparison | | A7 | Landing page → Free trial signup conversion rate, prior 3-month average | Unverified — `<VALIDATE: rate-landing-signup-baseline>` | Low | Same | | A8 | Free trial signup → Onboarding completion conversion rate, prior 3-month average | Unverified — `<VALIDATE: rate-signup-onboarding-baseline>` | Low | Same | | A9 | Onboarding completion → Paid conversion rate, prior 3-month average | Unverified — `<VALIDATE: rate-onboarding-paid-baseline>` | Low | Same | | A10 | Overall Ad click → Paid conversion rate, prior 3-month average | Unverified — `<VALIDATE: rate-overall-baseline>` | Low | Misstates whether a real drop occurred at all | **Claims tied to the stated primary concern** | Assumption ID | Claim | Source | Confidence | Consequence if wrong | |---|---|---|---|---| | A11 | No step has been pre-identified by the requester as responsible for the drop | Supplied | N/A | N/A — scoping fact, not a rate | | A12 | Candidate root-cause categories in scope once the leaking step is confirmed: landing-page/creative change, onboarding UX change, pricing/trial-term change, seasonality or external event, an instrumentation/tracking change coinciding with the drop | Unverified — `<VALIDATE: root-cause-category>` | Low (finding-critical; not to be narrowed before Section 4 pinpoints the leaking step) | Attributes the drop to the wrong lever and misdirects remediation | | A13 | No individual user-level session recordings may be accessed during this audit | Supplied (hard constraint) | N/A | N/A — bounds available evidence, not a rate claim | The step whose data quality is least certain is the Ad click → Landing page handoff: it depends on ad-platform click IDs reconciling correctly into Mixpanel events, which is the most common attribution weak point in a funnel of this shape. Onboarding completion is a secondary concern, since "completion" as an event definition can silently change if the onboarding flow itself was edited during the period. Section 9's tracking-integrity checks must probe the Ad click → Landing page handoff first, then Onboarding completion. ## 4. Diagnostic Findings and Drop-off Analysis | Step | Users In | Users Out | Conversion Rate | vs. Benchmark/Prior Period | Severity | |---|---|---|---|---|---| | Ad click → Landing page | `<VALIDATE: rate-ad-landing-current>` | `<VALIDATE: rate-ad-landing-current>` | `<VALIDATE: rate-ad-landing-current>` | `<VALIDATE: rate-ad-landing-baseline>` | Not yet determined — pending A1/A6 | | Landing page → Free trial signup | `<VALIDATE: rate-landing-signup-current>` | `<VALIDATE: rate-landing-signup-current>` | `<VALIDATE: rate-landing-signup-current>` | `<VALIDATE: rate-landing-signup-baseline>` | Not yet determined — pending A2/A7 | | Free trial signup → Onboarding completion | `<VALIDATE: rate-signup-onboarding-current>` | `<VALIDATE: rate-signup-onboarding-current>` | `<VALIDATE: rate-signup-onboarding-current>` | `<VALIDATE: rate-signup-onboarding-baseline>` | Not yet determined — pending A3/A8 | | Onboarding completion → Paid conversion | `<VALIDATE: rate-onboarding-paid-current>` | `<VALIDATE: rate-onboarding-paid-current>` | `<VALIDATE: rate-onboarding-paid-current>` | `<VALIDATE: rate-onboarding-paid-baseline>` | Not yet determined — pending A4/A9 | | **Overall (Ad click → Paid conversion)** | `<VALIDATE: rate-overall-current>` | `<VALIDATE: rate-overall-current>` | `<VALIDATE: rate-overall-current>` | `<VALIDATE: rate-overall-baseline>` | Not yet determined — pending A5/A10 | The single largest leak, by absolute user count, cannot be identified until A1–A10 are pulled (Section 7, Section 8). Once pulled, both the absolute-count drop and the percentage-point drop will be computed for each step; if the two disagree on which step matters most, the absolute-count framing takes priority for this audit's mandate (R1: prioritizing remediation work), since it is directly tied to the number of people lost — the percentage-point framing will still be reported alongside for context. **Findings** | Finding | Severity | Evidence | Confidence | |---|---|---|---| | F1: The overall paid-conversion rate for the last 30 days is lower than the prior 3-month average | Not yet determined | A5 vs. A10, both currently `<VALIDATE>` | Suspected | | F2: One specific step disproportionately accounts for the drop, rather than a roughly even decline across all four steps | Central open question of this audit | A1–A4 vs. A6–A9, all currently `<VALIDATE>` | Suspected | | F3: The drop coincides with a seasonality factor or external event rather than a funnel-specific issue | Not yet determined | Pending Section 9 seasonality check | Suspected | **Evidence rule:** this section is a draft diagnosis for review, not a confirmed report. Stakeholder presentation of any finding above is gated by Section 12 approval, not by the completion of this section. ## 5. Step and Segment Contracts **Ad click → Landing page** — Data source: Mixpanel (ad-click and landing-page pageview events). Current rate: `<VALIDATE: rate-ad-landing-current>`. Comparison basis: A6. Owner: growth/paid-media owner. **Landing page → Free trial signup** — Data source: Mixpanel. Current rate: `<VALIDATE: rate-landing-signup-current>`. Comparison basis: A7. Owner: growth/product owner. **Free trial signup → Onboarding completion** — Data source: Mixpanel. Current rate: `<VALIDATE: rate-signup-onboarding-current>`. Comparison basis: A8. Owner: product/onboarding owner. **Onboarding completion → Paid conversion** — Data source: Mixpanel. Current rate: `<VALIDATE: rate-onboarding-paid-current>`. Comparison basis: A9. Owner: product/monetization owner. **Segments not examined in depth:** per-channel or per-creative cuts within "ad click," device/platform cuts (mobile vs. desktop), and new-vs-returning-user cuts. None was named in the supplied FUNNEL_DEFINITION or CONTEXT_AND_CONSTRAINTS, and adding them would expand scope beyond the five stated steps without a supplied mandate to do so. These may be proposed as follow-up investigation once the leaking step is confirmed (Section 6, Section 13). **Internal vs. external claim separation:** raw per-step counts and rates, and any finding at Confidence: suspected, stay internal to the analysis team until Section 12 approval. Only findings that reach Confidence: confirmed, after Section 9 checks pass, may appear in a stakeholder-facing presentation. ## 6. Root-Cause Architecture and Evidence Map For F2 (which step, and why): | Hypothesis | Supporting evidence available now | Additional evidence needed | |---|---|---| | Landing-page/creative change | None cited in supplied inputs | Landing-page edit/deploy history for the period; A1 vs. A6 confirming the leak sits at this step | | Onboarding UX change | None cited | Onboarding-flow changelog for the period; A3 vs. A8 | | Pricing/trial-term change | None cited | Pricing/billing changelog for the period; A4 vs. A9 | | Seasonality/external event | None cited | A calendar check of the 30-day window for holidays, outages, promo end dates (Section 9) | | Instrumentation/tracking change | None cited | A change log for Mixpanel event definitions/SDK versions during the period (Section 9) | **Leading hypothesis:** none can be named yet. No evidence beyond the (as-yet-unconfirmed) drop-off number itself exists for any candidate above, and a drop-off number alone is a symptom, not a diagnosis. **Evidence map:** each "additional evidence needed" item above maps to F2. Owner for the step-specific changelog pulls is the corresponding step owner named in Section 5; owner for the Section 9 tracking-integrity and seasonality checks is the data/analytics team. **Causes considered and ruled out already:** none. No data pull has occurred yet, so no cause can be ruled out — a cause is ruled out only once evidence contradicts it. Any cause not listed above as a hypothesis is out of scope for this pass and would require a supplied reason to add. ## 7. Validation and Data Requirements | VALIDATE ID | What must be established | How to establish it | Dependent tasks/actions | Status until resolved | |---|---|---|---|---| | rate-ad-landing-current | Ad click → Landing page rate, last 30 days | Pull real current data (Mixpanel query) | Section 4 table, F2, P1 | No stand-in used; table cell and F1–F3 remain suspected | | rate-landing-signup-current | Landing page → Signup rate, last 30 days | Pull real current data | Section 4 table, F2, P1 | Same | | rate-signup-onboarding-current | Signup → Onboarding completion rate, last 30 days | Pull real current data | Section 4 table, F2, P1 | Same | | rate-onboarding-paid-current | Onboarding → Paid rate, last 30 days | Pull real current data | Section 4 table, F2, P1 | Same | | rate-overall-current | Overall Ad click → Paid rate, last 30 days | Pull real current data | Section 4 table, F1, P1 | Same | | rate-ad-landing-baseline | Ad click → Landing page rate, prior 3-month average | Pull real current data | Section 4 table, F2, P2 | Same | | rate-landing-signup-baseline | Landing page → Signup rate, prior 3-month average | Pull real current data | Section 4 table, F2, P2 | Same | | rate-signup-onboarding-baseline | Signup → Onboarding rate, prior 3-month average | Pull real current data | Section 4 table, F2, P2 | Same | | rate-onboarding-paid-baseline | Onboarding → Paid rate, prior 3-month average | Pull real current data | Section 4 table, F2, P2 | Same | | rate-overall-baseline | Overall Ad click → Paid rate, prior 3-month average | Pull real current data | Section 4 table, F1, P2 | Same | | root-cause-category | Which candidate cause (Section 6) actually explains the confirmed leak | Pull real current data (changelogs) / run real user research if changelogs are inconclusive | Section 6 leading hypothesis, P3, P4 | No leading hypothesis named until resolved | **Existing-data-first:** since Mixpanel already holds a year of history, no new tool or research is required to resolve A1–A10 — a straightforward query pull covering the stated 30-day window and the 3-month baseline resolves nearly every rate-based item above. Only root-cause-category may require checking product/pricing changelogs, or brief internal interviews with the relevant step owner, before it can move past suspected. No benchmark or rate anywhere in this report is invented for plausibility; every one is either sourced or carries a `<VALIDATE>` tag. ## 8. Investigation Sequence and Requirement Traceability 1. Pull current 30-day per-step Mixpanel data for all four steps plus the overall rate (resolves A1–A5). Depends on: none. Requirement: R1, R2. 2. Pull prior 3-month average per-step Mixpanel data from the same instance (resolves A6–A10). Depends on: Task 1. Requirement: R1, R2, R6. 3. Draft the Section 4 findings table and findings list from Tasks 1–2. Depends on: Tasks 1–2. Requirement: R1, R5. 4. Run Section 9 data-quality checks: tracking-integrity per step, seasonality/external-event check for the 30-day window, sample-size check for any segment cut used. Depends on: Tasks 1–2. Requirement: R1. 5. Confirm R3 held throughout Tasks 1–4 (no user-level session recordings were accessed). Depends on: Tasks 1–4. Requirement: R3. 6. Once Task 3 identifies the leaking step(s), pull the relevant changelog (landing page, onboarding, pricing, or Mixpanel instrumentation) for the 30-day window. Depends on: Task 3. Requirement: A12. 7. Update the Section 6 evidence map and, if evidence supports it, name a leading hypothesis at Confidence: data-supported. Depends on: Task 6. Requirement: A12. 8. Report any unresolved `<VALIDATE>` item and any data-quality blocker before stakeholder presentation is requested (Section 12). Depends on: Tasks 4, 7. Requirement: all. **Traceability table** | Requirement/Assumption | Finding/Step | Owner | Acceptance Check | |---|---|---|---| | R1 / A1–A5 | All four steps + overall | Data/analytics team | Mixpanel query result for the 30-day window, logged with query timestamp | | R2 / A6–A10 | All four steps + overall | Data/analytics team | Mixpanel query result for the 3-month baseline window, logged with query timestamp | | R3 / A13 | All steps | Data/analytics team | Confirmation logged that no session-recording tool was queried during Tasks 1–7 | | R4 | Funnel structure | Auditor | Section 4 table matches the five stated steps exactly | | R5 / A11 | F2 | Auditor | Section 4/6 name no step as cause before Task 3 completes | | R6 / A6–A10 | Baseline claims | Data/analytics team | Baseline sourced from Mixpanel history, not an external benchmark | | A12 / root-cause-category | F2, Section 6 | Product/growth lead | Changelog pull result logged for the implicated step | ## 9. Data-Quality and Readiness Checks A diagnosis is only as good as the data behind it. Every number in Sections 3–6 must be checked for quality before it is trusted, not just pulled and reported. | Assumption/Req | Check level | Method | Expected result | Pass condition | Prerequisites | |---|---|---|---|---|---| | A1–A5 (current rates) | data-pull | Mixpanel funnel query, last 30 days, per step | Five rate values returned with non-null counts | Non-null Users In/Out for every step | Mixpanel access | | A6–A10 (baseline rates) | data-pull | Mixpanel funnel query, prior 3-month average, per step | Five baseline rate values returned | Same | Mixpanel access | | Ad click → Landing page event firing | tracking-integrity-check | Confirm ad-platform click IDs reconcile into Mixpanel landing-page events at an expected match rate | Match/attribution rate consistent with prior periods | No unexplained drop in matched-event volume | Ad-platform click logs, Mixpanel raw events | | Onboarding completion event definition | tracking-integrity-check | Confirm the "completion" event fired by the same criteria throughout the 30-day window | Definition unchanged, or change logged and dated | Definition confirmed stable, or change explicitly flagged as a candidate cause | Product/engineering changelog access | | Remaining step event firing (Landing page, Signup, Paid conversion) | tracking-integrity-check | Spot-check each step's event volume against a known-stable upstream count | No anomalous gap inconsistent with A1–A4 | Counts reconcile within normal variance | Mixpanel raw events | | 30-day window (TIME_PERIOD) | seasonality-check | Check the window against a calendar of holidays, known outages, pricing changes, promo start/end dates | No unflagged external event overlaps the window, or any found event is logged | No event found, or found events logged as candidate causes (A12) | Internal calendar/changelog access | | root-cause-category | confirmed-finding | Changelog/interview evidence tied to the implicated step | Evidence supports or rules out at least one Section 6 hypothesis | NOT CONFIRMED until Section 12 approvals granted | Section 8 Tasks 6–7 complete | No `<VALIDATE>` item currently uses a stand-in estimate (Section 7), so no item here carries an additional "unconfirmed stand-in" note beyond what Section 7 already states. A tracking-integrity-check PASS proves only that the underlying data can be trusted for the step it covers. It does not prove that a cause is real — only a confirmed-finding row proves that, and only once Section 12 grants approval. The two are never conflated in this report. ## 10. Bias, Privacy, and Compliance Boundaries - **[High / Open]** Presenting F1, F2, or F3 as confirmed while any finding-critical Section 7 item remains unresolved is prohibited. No finding here may be shown to stakeholders as diagnosed until it reaches Confidence: confirmed per Section 9/12. - **[Medium / Open]** A tracking-integrity failure (for example, the Ad click → Landing page attribution check failing) must not be reported as a user-behavior finding. Mitigation: run the Section 9 tracking-integrity checks before any Section 4 rate is treated as real, and report a failed check as a data-quality blocker, not as evidence of user drop-off. - **[High / Standing]** No individual-level session recordings or user-level event traces may be viewed or exported at any point in this audit, per R3/A13. All analysis stays at the step- and aggregate-cohort level. - **[Medium / Standing]** The report may not attribute cause to an individual user, or make a demographic-based claim about a segment, without evidence explicitly gathered and logged for that segment. - **[Medium / Standing]** If a confirmed finding contradicts a stakeholder's prior belief about which step is failing, it is surfaced in Section 4/13 as stated, with its supporting evidence, rather than softened or omitted. - **[Low / Conditional]** Any segment cut finer than the four stated steps, should one later be added with a supplied reason, must be checked for re-identification risk before inclusion; none is currently in scope (Section 5). The risk that stays genuinely unassessable until Section 7's finding-critical items resolve is whether the paid-conversion drop has a single dominant root cause or several compounding causes — this cannot be judged from the drop-off numbers alone. ## 11. Reporting, Verification, and Correction Plan **Runnable now:** Section 8 Tasks 1–5 — the full Mixpanel pull, Section 4 drafting, and Section 9 tracking/seasonality checks — none require anything beyond existing Mixpanel access. **Blocked on validation:** Section 8 Tasks 6–7 (root-cause changelog pull and leading-hypothesis naming) until Task 3 identifies which step leaked. **Approved internal review:** draft findings (Section 4) are reviewed internally by the funnel owner before any Section 12 action moves to READY FOR HUMAN REVIEW. **Stakeholder presentation checks:** no finding is presented externally until every Section 9 check for the implicated step(s) shows PASS and every finding-critical Section 7 item touching that finding is resolved. **Approved final report** requires ALL of: Section 9 checks passing at their stated level for every step in the diagnosis; every Section 12 action resolved (approved or explicitly declined); every finding-critical Section 7 item resolved with real data, not a stand-in. **Bounded post-report verification:** after a recommended fix ships for the confirmed leaking step, re-pull that step's Mixpanel conversion rate for a comparable window and confirm it moved in the expected direction. Separately confirm no headline claim in the final report folded in the segments or channels excluded in Section 5. **Correction:** before issuing any correction, confirm who already received the report (recipients named in Section 1). Editing this file after a decision was already made on an earlier version does not undo that decision — containment means re-issuing the report with the change flagged, not a silent edit. ## 12. Data-Access and Publication Approval Register | Action ID | Purpose | Data/Scope | Expected Effect | Trigger Condition | Status | Approved by / Date | |---|---|---|---|---|---|---| | P1 | Pull current 30-day per-step Mixpanel data | Aggregate step-level counts/rates, last 30 days | Resolves A1–A5 | None — runnable immediately | READY FOR HUMAN REVIEW | ____ / ____ | | P2 | Pull prior 3-month average per-step Mixpanel data | Aggregate step-level counts/rates, 3-month baseline | Resolves A6–A10 | None — runnable immediately | READY FOR HUMAN REVIEW | ____ / ____ | | P3 | Pull changelog for the implicated step (landing page, onboarding, pricing, or Mixpanel instrumentation) | Internal changelog only, no user-level data | Begins resolving root-cause-category | BLOCKED BY VALIDATION: rate-ad-landing-current, rate-landing-signup-current, rate-signup-onboarding-current, rate-onboarding-paid-current | BLOCKED BY VALIDATION | ____ / ____ | | P4 | Present F1–F3 to stakeholders as confirmed findings | Section 4 findings + Section 9 check results | Informs roadmap prioritization | BLOCKED BY VALIDATION: root-cause-category and all ten rate items | BLOCKED BY VALIDATION | ____ / ____ | | P5 | Publish the final report beyond the immediate analysis team | Full report, aggregate data only | Broader team visibility | Blocked on P4 | blocked on prior action (P4) | ____ / ____ | Approving one action above never implies approval of another. Listing a correction action in Section 11 does not mean it is executed now. ## 13. Completion Evidence and Handoff A final report must contain: every confirmed finding mapped to its Mixpanel query or changelog source — currently none, since F1–F3 are all Confidence: suspected. **Section 9 checks status:** A1–A5 data-pull — NOT RUN; A6–A10 data-pull — NOT RUN; Ad click → Landing page tracking-integrity — NOT RUN; Onboarding completion tracking-integrity — NOT RUN; remaining-step tracking-integrity — NOT RUN; 30-day seasonality-check — NOT RUN; root-cause-category confirmed-finding — NOT RUN (BLOCKED, depends on the above). Suspected, data-supported, and confirmed findings are reported separately; a suspected cause is never presented as confirmed. As of this draft, F1, F2, and F3 are all Confidence: suspected. **Data-quality issues discovered:** checks have not yet been run, so this line is neither "NO DATA-QUALITY ISSUES FOUND" nor a list of issues — it updates to one or the other once Section 9 executes. **Unresolved Section 7 items, by name:** rate-ad-landing-current, rate-landing-signup-current, rate-signup-onboarding-current, rate-onboarding-paid-current, rate-overall-current, rate-ad-landing-baseline, rate-landing-signup-baseline, rate-signup-onboarding-baseline, rate-onboarding-paid-baseline, rate-overall-baseline, root-cause-category — all unresolved. **Residual limitations at handoff:** no per-channel/creative, device, or new-vs-returning cuts were examined (Section 5); no individual-level behavioral evidence was, or will be, used (R3). **Exact next steps:** execute Section 8 Tasks 1–8 in order, beginning with the Mixpanel pull (P1/P2). No data pull, research result, or approval in this report is fabricated. A well-argued hypothesis alone is not evidence of the actual root cause until it is confirmed.