Sumidatasumidata.io
Sign in
Docs/Meta/Changelog
Meta · Changelog

Changelog

Version history for the SDK, the Partner API, and the Dashboard.

01SDK 0.11.0: events keep the time they were called

Fix · SDK 0.11.0

Events and purchases sent before the SDK finished loading now carry the time of the call, not the time the queue was processed, so funnel steps stay in the order they happened.

  • The install snippet's queue stub now records the call time: push([m, a, Date.now()]). Old snippets keep working; their queued events use the time the SDK loaded, as before.
  • A purchase with its own timestamp keeps it.
i
Using the npm package? Update @sumidata/browser to 0.11.0. Using the script tag? Copy the updated snippet from Install.

02SDK 0.10.0: Sumidata.purchase()

New · SDK 0.10.0

Record an order from the browser with one call: Sumidata.purchase({ orderId, totalAmount, currency, items }). It returns nothing and never throws.

  • The SDK attaches the device, the session and the buyer you passed to identify(), so the order is linked to the session and its replay. An externalUserId on the order names a different buyer and wins.
  • Sumidata.push('purchase', [order]) works before the SDK has loaded - the order waits in the queue. Use it with the CDN snippet and Google Tag Manager.
  • A recorded order is silent; anything else (rejected, duplicate, dropped items, quota, not delivered) is logged to the console with the [Sumidata] prefix. The SDK does not resend on its own - if an order was not delivered, call purchase() again.
  • Sumidata.event('purchase', …) still does not record a purchase - use purchase().
  • Server-side ingest is unchanged: orders from your backend still go to POST /sdk/ingest.
i
Using the npm package? Update @sumidata/browser to 0.10.0. See Conversions & attribution and SDK configuration.

03Purchases: one event per order, products in items

Breaking change · Ingest API

A purchase is now one event per order. Send the order's products inside items (up to 200) instead of one purchase event per order line. Sales reports count orders, so the purchase count and average order value match your store.

  • A purchase with productId, productName, productCategory, quantity or unitPrice at the top level is no longer recorded - it comes back in skipped.
  • Duplicate protection is by orderId alone: a repeat of an accepted order, or a second event with the same orderId in one request, is skipped.
  • Items without productId, with an invalid quantity or price, or past the 200th are dropped and reported in the new warnings array; the order is still recorded.
!
Update your integration before this release reaches your project. See Conversions & attribution and Server-side ingest.
Coming soon
We're consolidating the release notes into a single feed.