A purchase count can look credible while the associated revenue is wrong by a factor of one hundred. That makes a value-unit check useful before an advertiser uses ChatGPT campaign revenue to decide whether to increase spend. Check the number, its currency and the business amount it represents as three separate properties.
This procedure covers monetary scale in the measurement pipeline. It does not estimate profitability or repair attribution. A perfectly encoded purchase may still be outside a campaign’s attribution rules, and a correctly attributed sale may still lose money after fulfilment costs.
Follow a specific order through the pipeline
Choose an authorized sample order whose total is known from the order system. Record the order amount as displayed to the customer, the stored amount and currency, and the value assembled for the outgoing event. Use a safe order reference rather than customer information in the investigation notes.
The sample should contain a fractional amount when the currency permits it. A round total such as 100 can conceal a conversion or rounding mistake. A hypothetical SEK 249.50 order makes the expected minor-unit event amount 24950. The currency travels with that integer; the number alone is not a complete monetary value.
OpenAI’s conversion tracking documentation specifies standard currency minor units for event amounts. Do not assume every currency has two decimal places. A currency without a fractional minor unit needs different handling from SEK or USD. Use the currency definition in the implementation rather than a universal multiplication by one hundred.
One purchase, different numeric formats
- Order
SEK 249.50 in the store order view.
- Purchase event
24950 in the currency minor unit, with currency SEK.
- Report
Check the report field currency and scale separately.
Separate storage conventions from transport conventions
A commerce database might store amounts in minor units already. If an integration multiplies that stored integer again, it inflates the event. Another system may expose a decimal major-unit value and need a deliberate conversion. Inspect actual values from the active code path instead of inferring the convention from a variable named price or total.
Document the boundary in a small mapping: source field, source unit, transformation, destination field and destination unit. Include rounding policy and the point at which rounding happens. Repeated decimal conversions can introduce small discrepancies that become difficult to explain across many orders.
If browser and server both send a purchase, compare their monetary payloads for the same action. Matching event IDs address duplicate identity; they do not by themselves establish agreement on amount or currency. Follow the event-ID contract while checking value consistency independently.
Decide which order total the amount means
The integration owner and finance owner should agree whether the event value includes tax, shipping, discounts or only merchandise. This is an internal accounting choice that must remain consistent with the field’s documented requirements. Do not change the basis silently to improve the apparent return on ad spend.
For example, a hypothetical checkout contains merchandise of SEK 300, a SEK 60 discount and SEK 49 shipping. Sending 300, 240 or 289 as a major-unit equivalent tells three different stories. The correct choice for your internal analysis depends on the declared definition, but the choice cannot vary between browser and server or between product categories without explanation.
Keep order-level adjustments separate from numeric scale. A refund changes the economic outcome; dividing a wrongly scaled number by one hundred repairs a representation error. The refund analysis guide handles the former without pretending that it is simply an encoding problem.
Read reporting values using reporting rules
Never copy the event’s minor-unit rule into every report calculation. Reporting fields and campaign budget fields have their own units. Confirm the specific report schema and account currency before comparing an exported value with the event payload. Budget micros belong to a separate configuration boundary covered in budget-unit conversion.
If transaction and account currencies differ, retain the original transaction currency in the audit evidence. A reporting total expressed in the account currency cannot be reconciled by summing raw integers from mixed-currency events. Establish what conversion information is available before claiming a precise order-to-report match.
Test boundaries, not only one ordinary purchase
Review a small set that exercises the actual store: a discounted order, a fractional amount, a zero-decimal currency if supported, and an order with shipping. Include a high but valid total to expose numeric limits. These are implementation checks, not a reason to create artificial live customer transactions.
For each case, write the expected amount before inspecting the emitted payload. Otherwise an investigator can unconsciously accept whatever the implementation returns. Preserve the expectation, observed value and explanation for any difference in the same test record.
If a defect is found, estimate its affected date range and routes before correcting historical analysis. Mark the relevant revenue figures as unreliable while the scope is unresolved. A repaired sender proves that future encoding changed; it does not prove that earlier reports were automatically restated. Close the investigation with the corrected mapping, verified sample values and a clear note describing which historical decisions need review.
Sources and scope
Verify the numeric scale and currency of purchase-event values across order systems, event delivery and reports.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.