Reading your events

What one recorded event contains, where it comes from, and what (honestly) is not in it yet.

What an event records

Every request handled by the gateway — including pass-throughs — becomes one small event. In merchant terms, an event says:

  • When: a UTC timestamp.
  • Who: the requester kind (agent / human / crawler / protocol), the platform when identifiable, and whether the identity was cryptographically verified.
  • What they asked for: the URL on your store, and technical request context like the Accept header and referrer.
  • What they got: markdown, your normal HTML, or a protocol response — plus how many milliseconds the response took to produce.

That is the whole record. There is no shopper identity in an event — no names, emails, accounts, or payment data.

Where events come from

The gateway on your store forwards each event to Rebilder’s events endpoint, authenticated with your store’s API key. Events then appear in Console → Agent visits and roll up into the Overview numbers. Reporting is fire-and-forget: if the events service were slow or down, your store would not notice.

Outcomes: joined onto visits, not embedded in them

An event never carries an order at the moment it is recorded — orders arrive separately, through your Shopify order webhook or the outcomes API, and are joined onto the visit stream when the funnel reads them. That join is live: the Funnel (a Pro surface) shows orders next to your agent traffic, with each order labeled by its evidence — explicitly attributed, lookback-inferred (marked as inference), or unattributed. Nothing is ever guessed into a “conversions” number.