Measurement / framework / Free to use

Purchase ID Quality Review Framework

Find missing, repeated and reused purchase IDs before relying on ecommerce event counts.

Growthcraft Editorial · 2026-11-03. AI-assisted research and implementation. Examples are synthetic; Akshay's personal review is not claimed.

Copyable template

Select and copy the complete template below. With JavaScript enabled, you can edit, copy and download it in the interactive workspace.

PURCHASE ID QUALITY REVIEW — WORKSHEET
Decision: [Which purchase measurement decision depends on this review?]
Owner and reviewer: [roles]   Next check: [date and time]
Source and stage: [raw export / platform report / other]. Do not mix them.
Property, stream, event, market, exact period and timezone: [fill in]
Extract timestamp and expected processing delay: [fill in]
Eligible purchase event rows and exclusions: [define tests, refunds and revisions]
ID comparison rule: [case-sensitive? whitespace treatment? source-specific namespace?]
Independent order evidence available and permitted? [yes / no / unknown]

COUNTS FROM ONE EXTRACT
Nonblank ID rows: [N]
Distinct nonblank IDs in those same rows: [U]
Missing, null or blank ID rows: [M]
IDs independently confirmed to identify more than one order: [C / unknown]
State how many IDs were reviewed. An observed zero in a partial review is not a clean bill of health.

CHECK AND CALCULATE
Total rows = N + M. Missing-ID share = M / (N + M), unavailable for zero rows.
Repeated-ID rows = N - U. Share of nonblank rows = (N - U) / N, unavailable when N is zero.
Each confirmed reused-ID group must appear at least twice. C cannot exceed U or N - U.
These are row-profile metrics. N - U is not proven duplicate sales; separate orders can share an ID. M rows can relate to orders already in N. Neither U nor N + M is the true number of orders.

SYNTHETIC EXAMPLE
N=90, U=75, M=10, C=4. There are 100 rows; 10% lack an ID. There are 15 repeated-ID rows (16.7% of nonblank rows). Four IDs have been confirmed against permitted order evidence as identifying more than one order. Other IDs may be unreviewed. Do not subtract 15 from sales or declare 75 orders.

REVIEW AND RESPONSE
1. Inspect a permitted sample of repeated IDs for confirmation-page reloads, retries or genuinely separate orders sharing a key.
2. Check missing/blank ID handling at the source and never replace missing IDs with an empty string as a fix.
3. Check whether the stable order reference is unique for the relevant stream and contains no personal data; verify collisions within approved systems.
4. Compare source logging, collection and platform reporting only after confirming their scopes, latency and documented product-specific rules. Do not assume raw rows equal the reported purchase metric.
5. Record finding, review coverage, owner, next check and any decision to hold. Do not send customer records, order IDs or secrets to an AI model.
Finding | evidence | affected scope | reviewed IDs / total | owner | next check | decision held

The decision this review supports

When a purchase report changes suddenly, an event row is not necessarily a separate order. A confirmation-page reload or delivery retry may repeat the same order; a reused ID may make separate orders look like one. This framework helps an ecommerce or analytics owner decide what to investigate before using the numbers for a marketing decision.

When to use it

Use one completed purchase-event extract from one defined collection source, property, stream and period. It is useful when you can distinguish nonblank and blank IDs and know the number of distinct nonblank values. It is not an estimate of actual orders. If the source is sampled, incomplete, contains mixed event types or cannot be accessed under your organisation's rules, record that limitation and resolve it before comparing.

Five checks before presenting a number

Write the decision, owner, dates, timezone, source stage and processing delay. Identify test orders, refunds and late arrivals separately.
Count purchase-event rows with a nonblank ID and those without one. Document case, whitespace and namespace rules before counting distinct IDs.
Count repeated-ID rows as nonblank rows minus distinct nonblank IDs. This is a signal for review, not a duplicate-order count.
Where an authorised, reliable order record exists, inspect whether any one ID represents multiple different orders. Record review coverage; an unreviewed collision is unknown.
Assign a role and deadline to trace missing IDs, repeated firing and confirmed key reuse. Compare platform reports only after checking the platform's own rules and latency.

Worked example

A synthetic extract has 90 rows with a nonblank ID, 75 distinct nonblank IDs and ten rows without one. Four IDs were confirmed in a partial review to identify different orders. There are 100 rows, ten per cent without an ID, and 15 repeated-ID rows, or 16.7% of the nonblank rows. The remaining IDs are not necessarily reviewed. Neither 75 nor 100 is a verified order count. Use the calculator to check the arithmetic.

Decision and handoff

Hold a sales or budget conclusion that requires trustworthy order counts until the data owner has reconciled the relevant evidence. Ask the implementation owner to check event firing and the order-ID source; ask the reporting owner to document what the platform counts. The review prompt can draft an anonymised handoff. Never paste real order or customer records into it.

Sources and limits

Checked 3 November 2026: Google's transaction-ID guidance covers purchase deduplication for web streams, including empty-ID and reused-ID risks. Google's diagnostics guide describes missing and non-unique purchase identifiers. Adobe's purchaseID guidance, updated 28 September 2026, documents different product rules. This worksheet is an original review method, not vendor advice or a guarantee of report corrections.