Report revenue
Grona measures mobile campaigns against revenue, and the revenue that counts comes from your order system, sent server to server. The app reports purchases too, but those events are for joining, not for money. This page explains why, which fields Grona needs, and how your order records join to campaign events.
Why revenue comes from your order system
Section titled “Why revenue comes from your order system”The device user may be an attacker, and anything the app reports can be changed on the device, including a purchase event and its total. So Grona uses the app’s purchase events only to join orders to the campaign events of the same install and shopper. Revenue truth comes from your order system, which knows what was charged.
What the app sends
Section titled “What the app sends”Your app tracks a purchase event when an order completes. It carries these fields:
| Field | Meaning |
|---|---|
order_id |
Your order id, for example ord_1001 |
total_minor |
The order total in minor units, for example 5200 for 52.00 |
currency |
The currency of your latest basket snapshot, for example USD |
campaign_product_ids |
Only the products in the order that Grona campaigns showed or added in this session |
treatments |
The treatments your order backend applied, as display data |
The event never carries the full basket. Campaign events are the exception: on keyed placements such as cart_line, they carry the line’s product id as their key, in every arm. So while a cart_line campaign is live, the product ids of the cart lines bound to it leave the device. See Track events for Android or iOS.
What to send from your order system
Section titled “What to send from your order system”Send every order placed through the app, not only orders that redeemed a grant. Analysis compares the treatment arm with the control arm over everyone assigned, so orders from control and untreated shoppers count as much as treated ones.
| Field | Example | Why Grona needs it |
|---|---|---|
| Order id | ord_1001 |
Matches the order_id in the app’s purchase event, which links the order to the install, the shopper and the campaign events |
| Customer id | cus_7Hq2Lm9x |
The same opaque id your app passes to identify |
| Order total in minor units | 5200 |
The revenue figure, as your order system charged it |
| Currency | USD |
Says which currency the total is in |
| Redeemed grants | jti, cmp, var, trt and val for each grant the order used |
Ties redemption to the grant Grona issued and to the campaign events that name it |
Your redemption table already holds the grant fields for each order. See Grants and order verification.
How the records join
Section titled “How the records join”| Join key | Connects |
|---|---|
| Order id | Your order record and the app’s purchase event. The event links the order to the install id, the customer id and the session |
Grant jti |
The grant Grona issued, the eligible and served events that carry it as grant_jti, and your redemption record |
| Campaign events | eligible, served and the other campaign events carry the campaign, variant, arm and unit, so revenue can be split by arm |
The grant’s jti matters because issuance alone overstates who was treated. A minted grant can fail to reach the device, arrive after the shopper left, or expire first. Joining on jti ties exposure, issuance and redemption together. Events and exposure explains how each event is used in analysis.
How to deliver it
Section titled “How to deliver it”There is no public endpoint for order data yet. Grona agrees the delivery method and format with you. Contact Grona through Get help to set it up.