Does consent apply to server events too?

The most common misconception about server-side tracking is that consent no longer applies. It does: what matters is which data about a person is processed, not the route it arrives by.

{
  "event_id": "order-12345",
  "event_type": "purchase",
  "consent_state": "granted",
  "consent_purposes": ["analytics", "marketing"]
}

The state has four values: unknown, denied, partial and granted. Take it from what your CMP reported at the time of the event rather than defaulting it to granted.

Orders without consent

Not every order has a decision behind it: someone ignores the banner, has JavaScript turned off, or the order is placed at a till in the shop. Orders from before you set things up carry none anyway. Such orders arrive with consent_state unknown, and someone who refused in the banner with denied. Without an exception, both would drop out of your revenue entirely.

The exception is revenue reconciliation: a purpose of its own, separate from tracking. It does not rest on consent but on your legitimate interest in complete revenue figures you can reconcile with your shop. For orders without a decision it is on by default for every account, and you can switch it off (see below). For orders after a refusal only with the additional instruction for revenue reconciliation, which you sign and we then activate: refusing tracking is not an objection to revenue reconciliation, but you need to weigh this case separately.

Before storing, the collector removes everything that ties the order to a person or a visit: pseudonymous ID, session, customer ID and email hash, click, impression and view IDs, IP hash, page, referrer, campaign parameters, the new-customer flag, line items, the value breakdown and free-form fields. What remains is the order ID, amount, currency, the day of the order without the time (in your shop’s time zone) and the environment. The order itself creates no journey, and nothing is sent to ad platforms.

The order ID stays so that a refund can find its purchase and you can reconcile revenue against your shop. In reports the order appears as unattributed, with the reason “No consent”. The revenue is measured, and no channel receives it. Because your shop can link the order number to a person, the data generally remains personal data: access, erasure and objection work through the order number (help article “Additional instruction for revenue reconciliation”).

Switching revenue reconciliation off

If you do not want orders without consent at Metrunio at all, switch revenue reconciliation off in the portal under Privacy. Only the Admin role can do this, and the change is recorded in the change log. From then on Metrunio rejects purchases and refunds without a decision, and an activated additional instruction for orders after a refusal is paused, because it requires revenue reconciliation. Orders with consent count as before. Your measured revenue is then lower than your shop’s by the rejected orders. For about ten seconds after the switch, an order may still be handled under the old setting.

Switching off does not delete what is already stored: those orders stay until the end of your raw data retention period and then disappear. If a single order should go at once, record an objection under Privacy with the order number as the identifier. You can switch revenue reconciliation back on at any time in the same place; rejected orders are not recovered.

When the browser reports the same order with consent

On Shopify, the Web Pixel reports the completed checkout with the order ID and the checkout identifier, but only if the customer has consented. If the purchase arrives through the webhook without a decision (typical for “Buy it now” and other dynamic checkouts that never create a cart), it stays unattributed with the reason “No consent”, and its revenue is measured. If you switch on order attribution via the checkout, Metrunio attributes it to the visit when the same checkout identifier arrived from the browser with consent and the consent already existed at the time of purchase. How that works and which limits apply is in the article “Attributing orders via the checkout”.

It is still counted only once: the confirmation from the browser is not a second purchase. Even if you report the same purchase as purchase through two routes, it counts once as long as both reports carry the same order number; the first one applies. If that was the report from the server without consent, the order stays unattributed, as described above. See the article on sending order data from your shop.