Not from those two totals alone. Current saved selections count entries still present at one moment; wishlist-attributed paid units count purchased quantities during a period. Their ratio is not a supported wishlist conversion rate.
For this month’s report, replace the percentage with two separately labelled totals. A selection-level conversion rate needs a cohort: a fixed group of saved selections followed over a stated window, with purchase outcomes linked to that group.
Replace the percentage with two dated totals
Copy this reporting block, replace the placeholders, and keep the cautions beside the figures:
- Saved selections as of [timestamp]: [count] entries currently saved.
- Wishlist-attributed paid units during [period]: [count] units recorded under [paid-order and attribution rules].
- Interpretation: These totals do not establish a matched conversion cohort: one counts current saved entries, the other counts paid units over time. Saved selections are not verified unique shoppers. Attribution does not establish that the wishlist caused the purchases.
- Coverage: [Time zone, captured activity and known gaps]. Mark undocumented tracking or attribution coverage as unconfirmed.
Confirm that “saved selections” means current entries rather than save events during the month. Also confirm the paid-order and attribution rules, exact period boundaries and whether the end boundary is included.
Ask which sessions and purchase routes the attribution method can connect. A missing purchase link does not prove that a saved selection went unpurchased. Do not present undocumented coverage as complete storewide tracking.
Trace the mismatch in a hypothetical ledger
This is an invented example, not observed store results. Assume every listed save is a first save, all dates are in 2026 and use UTC, and observations stop at May 1, 00:00.
These are all relevant selections and attributed purchases through that cutoff, with no refunds or cancellations. Purchase links are known for illustration; your report may not retain them.
- Selection A: Saved March 20; two units purchased and paid for on April 8; remains saved.
- Selection B: Saved April 2; one unit purchased and paid for on April 12; removed April 14.
- Selection C: Saved April 10; remains saved; no attributed paid purchase recorded by the cutoff.
- Selection D: Saved April 20; remains saved; no attributed paid purchase recorded by the cutoff.
- Selection E: Saved April 29; remains saved; no attributed paid purchase recorded by the cutoff.
At the cutoff, A, C, D and E remain saved. The completed reporting lines are:
- Saved selections as of May 1, 2026, 00:00 UTC: 4 current entries.
- Wishlist-attributed paid units during April 2026: 3 units, covering April 1, 00:00 UTC up to but not including May 1, 00:00 UTC, using the example’s assumed purchase links.
Three divided by four produces 75%, but not a supported conversion rate. A’s save predates April, B contributes paid units but is missing from the snapshot, and A’s two units represent one saved selection.
The numerator and denominator do not describe the same selection set or counting unit. Removing another saved entry would also change the ratio without another purchase.
Request linked records and agreed definitions
Send the report owner this four-part request. Ask them to flag anything unavailable rather than assume the software retains the necessary history:
- Selection history: Please provide stable selection references, product or variation identities, first-save times, and removal/re-save history.
- Linked purchase records: Please provide paid-order lines connected to those selections, payment times and purchased quantities.
- Attribution documentation: Please document the matching rules, activity and purchase routes captured, and known coverage gaps.
- Definitions to agree: Please confirm cohort eligibility, a count-once rule for qualifying selections, the purchase-observation window, and treatment of repeat saves, refunds and cancellations.
The first three items request records and documentation. The fourth establishes how those records will be counted; it is not a claim about an existing reporting feature.
Apply a proposed cohort to the same ledger
One hypothetical specification is selections first saved in April, each followed for 30 days after its own save. Thirty days is an illustrative choice, not a recommended benchmark.
For this specification, count a selection once if it has at least one qualifying attributed paid purchase within its window, regardless of purchased quantity or repeat orders.
Under that definition, B–E form the April cohort. A is excluded because its first save was in March. B remains in the cohort despite its removal; removing an entry must not silently change this fixed denominator.
At the May 1 cutoff, the cohort is still pending. E’s April 29 save, for example, has not had 30 days of follow-up. Later purchase outcomes are unknown, so this ledger cannot supply a finished cohort percentage.
Decide what you can publish
Use the available evidence to choose the next reporting step:
- Only aggregate totals or unconfirmed linkage: Report the two descriptive totals with coverage limits, and request the missing records.
- Linked cohort but incomplete follow-up: Keep the cohort pending rather than label the rate complete.
- Verified matching records, agreed rules and completed windows: For a nonempty cohort, divide the number of eligible selections with at least one qualifying attributed paid purchase within their observation window by the total number of eligible selections, then express the result as a percentage.
Label any completed result a recorded, attributed selection-level rate, not a unique-shopper rate. Include the cohort dates, observation window and coverage limits.
For this month’s report, fill in the two dated totals, flag any unconfirmed coverage, and send the four-part request to the report owner.
