Track ecommerce events
Record product views, add to cart, checkout start and payment submitted from the browser — and understand why completed purchases are not in this list.
Beyond automatic page views, the SDK exposes four funnel events. They tell you where visitors drop off and they give the attribution engine more touchpoints to work with.
The four events
All of them are on the default export, and none of them need the script id — the
SDK already knows it from init.
import clakta from "@clakta/javascript"Product view
Call it on a product detail page:
clakta.pageViewWithProduct({
id: "sku-1042",
name: "Blue shirt",
price: 29.99,
currency: "USD",
})Add to cart
clakta.addToCart({
id: "sku-1042",
name: "Blue shirt",
price: 29.99,
currency: "USD",
quantity: 1,
})Checkout started
clakta.checkoutStarted({
orderId: "1042",
token: "checkout-token-abc",
email: "customer@example.com",
currency: "USD",
value: 59.98,
lineItems: [
{ id: "sku-1042", name: "Blue shirt", price: 29.99, quantity: 2 },
],
})Payment submitted
Fire this when the shopper submits payment, before you know whether it was approved:
clakta.paymentSubmitted({
orderId: "1042",
currency: "USD",
value: 59.98,
})This event records an attempt. It never creates an order and never counts as revenue. Completed purchases are recorded only through the authenticated Orders API — see Send orders from your server.
This is deliberate: anything the browser can send, a hostile browser can forge.
Recognised fields
Clakta reads the fields below and stores anything else you include as metadata, so you can pass the object shape your platform already produces.
Products — id, name, price, currency, quantity
Orders / carts — orderId, token, email, currency, value,
lineItems
Prices are plain numbers in major units: 29.99, not 2999. Currency codes are
ISO 4217.
Pass token on checkoutStarted if your platform has a cart or checkout token.
It is the cleanest way to reconcile a browser checkout with the order your
backend later posts.
Custom events
For anything outside the ecommerce funnel:
clakta.trackEvent("hero-cta", "click", { variant: "A" })The first argument is your identifier for the thing being tracked — a button id, a section name. The second is the kind of event. The third is optional free-form metadata.
Where to put the calls
- Product view — on mount of the product detail page. In a single-page app, make sure it fires again on client-side navigation between products.
- Add to cart — in the success path of your add-to-cart handler, not on the click. Firing on click counts failed additions.
- Checkout started — when the checkout page or step first renders.
- Payment submitted — in the submit handler, right before the redirect to your payment provider.
Calls made before init finishes resolving the project configuration are held
and replayed, not dropped. You do not need to defer your calls behind a readiness
check.
Privacy-friendly projects
The events all work, but no browser session identifier is attached — the server
groups them with the same anonymous daily hash it uses for page views. Avoid
passing email on checkoutStarted in a privacy-friendly project; it is
personal data you have chosen not to collect.
Verifying
Turn on debug logging while you wire these up:
clakta.init({ id: "YOUR_SCRIPT_ID", debug: true })Every event is then logged to the console as it is sent, which is much faster than inspecting network payloads.
Related
Related articles
How Clakta tracking works
The path a visitor takes from an ad click to an attributed order, and which part of the system is responsible for each step.
Tracking modes
Privacy-friendly or full attribution — what each mode collects, how sessions are built in each, and what changes in your data when you switch.
Identify customers
Attach a known person to the current session with clakta.identify(), so journeys follow the customer instead of the browser.