A ChatGPT campaign reports purchases, yet attributed sales or ROAS is unavailable. The first question is not whether the products were free. It is whether valid monetary values accompanied the counted purchase events and whether the report can calculate the requested metric in that context.
Purchase occurrence and purchase value are different pieces of evidence. An event count can be present while some or all amounts are missing. Diagnose the coverage gap before using the report to rank campaigns by revenue efficiency or to decide that a campaign generated no commercial value.
Identify exactly which value is unavailable
Record the endpoint or report, field name, date range, entity scope and extraction time. A blank interface cell, a null API value and a numeric zero should not be treated as equivalent observations. Preserve the raw representation in the investigation so display formatting does not erase the distinction.
OpenAI reporting documentation explains that unavailable monetary values can be null and that ROAS depends on purchase values and spend. If revenue exists but spend is zero or unavailable, the ratio problem differs from missing purchase amounts. Diagnose the numerator and denominator separately.
Also confirm that the counted events are purchases. A campaign’s overall conversion total can describe other configured actions. Comparing all goal conversions with a purchase-value field may create an apparent inconsistency even when each field is behaving according to its definition.
Measure value coverage before estimating anything
Where the report supplies event counts and value counts for the same population, compare them. In a hypothetical example, ten attributed purchases have amounts on eight events. That is 80 percent value coverage, not proof that the remaining two purchases were worth zero.
Keep the coverage denominator explicit. A count from one campaign and a value count from an account-wide export cannot support a meaningful percentage. Hold the event selection, windows, time basis and breakdown constant so the gap actually describes missing values in the intended population.
If only a total is available, do not fabricate a coverage percentage. State that value completeness is unknown and inspect authorized sender diagnostics or internal order records. A limitation that is visible is easier to manage than a precise-looking figure with no support.
Purchase count is not value coverage
- 10 purchase events
The observed count of attributed actions.
- 8 with value
80 percent value coverage if the fields share the same population.
- 2 unknown
Missing value must not become zero or an average without labeling.
Trace the amount from the order system
Choose a small set of affected orders from the period and inspect the mapping into the event payload. Check whether the amount is absent, empty, malformed or populated only after the sender fires. Review currency alongside amount because a monetary number without the required currency context may not be usable.
A hypothetical failure occurs when a confirmation page sends the purchase event before its asynchronous order details finish loading. The action is recorded, but the amount is not yet available. Another possible failure is a server mapping that reads a field present for card payments but absent for an alternative payment route.
These examples are diagnostic possibilities, not claims about your implementation. Compare successful and affected orders by sender version, payment route, currency and checkout path. A pattern limited to one route gives a more useful repair target than a broad instruction to reinstall tracking.
Separate absent amounts from wrong units
If an amount exists but is one hundred times too large or too small, use the purchase-value unit audit. That is a scale defect. If the amount is absent, multiplying an aggregate by a conversion factor will not recover the missing information.
Check browser and server payloads independently when both routes are active. Do not assume that the route with the complete amount will necessarily repair incomplete information sent elsewhere. Verify the documented delivery behavior and the actual observed result after the integration is corrected.
The event-source audit helps when the inspected orders appear to reach a different source from the campaign being reported. A valid amount in the wrong source does not establish coverage for the intended campaign.
Keep estimates outside reported revenue
An internal planning model may estimate missing amounts using suitable order evidence. Label that estimate, describe its basis and retain observed revenue separately. Missing values may be concentrated in high-value or low-value orders, so a simple average of known values is not automatically representative.
For example, if all missing amounts come from invoice orders, the known card-order average may be a poor substitute. A sensitivity range can show whether the uncertainty changes the budget decision without pretending that the missing events have been reconstructed exactly.
Use null-metric handling to preserve unavailable values through spreadsheets and dashboards. Defaulting null to zero makes downstream totals appear complete and can hide the defect from the next analyst.
After repair, verify new events and document the affected historical interval. Do not claim older reports have changed unless that is confirmed. A responsible close names the broken mapping, the verified correction, current coverage and any revenue figures that remain unsuitable for comparison. That lets campaign operators continue using reliable counts while withholding financial conclusions the incomplete values cannot support.
Sources and scope
Diagnose missing monetary coverage when attributed purchase counts exist and avoid treating unavailable revenue as zero.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.