# Fictional Conversions API review

Every account, receipt, person, event, and count below is invented for teaching. These are not Maestro results or records from LinkedIn. This record contains no executable upload payload.

## The setup

Fictional Acorn Apps records a trial activation when a workspace completes its first import. A trial signup alone does not qualify. The source is an append-only product event log. Implementation owner Mira selected direct API because the product backend already emits this event; maintenance owner Jo owns the delivery queue.

Fictional receipt ACCESS-A records approved API access, rw_conversions and r_ads, and Mira's ACCOUNT_MANAGER role for ACCOUNT-A. VERSION-A records an October 29, 2026 check of supported version 202610. DATA-A records permission to use the proposed email-derived identifier. TEST-A authorizes a bounded two-action test, not an ongoing production release. MAP-A records enabled server rule SERVER-TRIAL-A, method CONVERSIONS_API, type START_TRIAL, no monetary value, plus separate browser rule BROWSER-TRIAL-A in the same account. ASSOC-A records both rules associated with campaign CAMPAIGN-A. MODEL-A records Each campaign attribution, 30-day click and 7-day view windows, with the report's stated date basis retained in REPORT-A.

The fixed test occurrence window is October 29, 2026, 10:00–10:05 UTC; review time is 11:00 UTC. SOURCE-A contains exactly two qualifying actions in that window. No other account, campaign, or source snapshot is included. The reporting date basis in REPORT-A is conversion occurrence date, October 29 UTC. These fictional settings are supplied facts, not defaults for your account.

## Action and attempt ledger

The labels below stand in for private references. The timestamp conversion and identifier checks are recorded in PAYLOAD-A: actual occurrence times converted to epoch milliseconds within the past 90 days; email lowercased and whitespace removed before SHA-256. No email or hash is reproduced.

| business_action_id | attempt_id | channel | conversion_rule | event_id | occurrence_utc | response | receipt |
|---|---|---|---|---|---|---|---|
| ACTION-1 | B-1 | browser | BROWSER-TRIAL-A | EVENT-1 | 2026-10-29T10:01:00Z | browser request observed | BROWSER-A |
| ACTION-1 | S-1 | server | SERVER-TRIAL-A | EVENT-1 | 2026-10-29T10:01:00Z | HTTP 201 | SERVER-A |
| ACTION-2 | B-2 | browser | BROWSER-TRIAL-A | EVENT-2 | 2026-10-29T10:03:00Z | browser request observed | BROWSER-B |
| ACTION-2 | S-2 | server | SERVER-TRIAL-A | EVENT-2 | 2026-10-29T10:03:00Z | timeout; no response captured | QUEUE-B |

BROWSER-A/B record event-specific Insight Tag calls with event_id. SERVER-A and QUEUE-B retain the matching API eventId labels. Both actions use ACCOUNT-A. No retry has run. Browser request observation proves the request was observed, not platform acceptance.

REPORT-A is an aggregate conversion breakdown with one attributed conversion under BROWSER-TRIAL-A and zero under SERVER-TRIAL-A. It includes both rules in the stated scope, but does not identify ACTION-1 or ACTION-2. No member-level matching diagnostic or event-level deduplication receipt is supplied.

## The review

Implementation readiness was Ready for authorized test: route, access, scope, mapping, data permission, and the two-action test authorization were recorded. The test now needs delivery reconciliation for ACTION-2. A production release remains outside TEST-A.

| Outcome | Conclusion | Evidence and limit |
|---|---|---|
| Source actions | Verified: two qualifying actions | SOURCE-A |
| Server acceptance | ACTION-1 verified; ACTION-2 unknown | SERVER-A is HTTP 201; QUEUE-B is an ambiguous timeout |
| Member matching | Unknown for both actions | No matching receipt supplied |
| Browser/server deduplication | Configuration checks verified; observed event handling unknown | MAP-A and browser/server ID records agree. REPORT-A is aggregate and cannot prove which action was discarded or counted. |
| Attribution | Aggregate report verified; per-action attribution unknown | REPORT-A shows one browser and zero API conversions within its scope. It does not identify the source action. |

Two distinct actions produced two browser attempts and two server attempts. There were zero retries. One server attempt has known acceptance, zero have known rejection, and one has an unknown outcome. The attempt acceptance rate is unknown because an outcome is missing. Confirmed server-delivery coverage is 1 / 2 = 50% of source actions; label this confirmed coverage, not the final acceptance or match rate. The final delivery coverage remains unknown until ACTION-2 is reconciled. No match rate or deduplication rate can be calculated from these inputs.

Jo should retrieve the delivery outcome for S-2 before deciding whether to replay it. Preserve ACTION-2 and EVENT-2 in the investigation. The browser/server documentation does not guarantee safe deduplication of an arbitrary server retry. The report's zero API-attributed conversions does not prove that S-1 failed.

## Two boundary cases

If SOURCE-A instead contains zero actions and there are zero attempts, coverage and attempt acceptance rates are not applicable because the denominators are zero. Matching and attribution remain untested; do not manufacture a successful test from zero activity.

If ACCOUNT-B, another rule, or a different source snapshot appears in the evidence, split it into a separate review. Matching an event_id string across accounts does not establish redundant-event deduplication. If the same account reuses EVENT-1 for another business action, flag an identity collision and hold that implementation decision.