Pixels & conversion tracking

A pixel sends your storefront’s customer events — page views, product views, add-to-cart, checkout, purchase — to an external ad or analytics platform so it can measure conversions, build audiences, and optimise your ad spend. Sellerlane gives you one place to connect, configure, test, and troubleshoot every pixel, with consent gating built in.

You manage pixels under Settings → Pixels (the page itself is titled Customer events). An operational view also lives at Analytics → Pixels, where you can inspect dispatches and their skip reasons — and re-send a delivery that failed.

Note

Parts of this page are Administrator-only. Credentials, the Google Ads sign-in, and the consent requirements are reserved to the store Administrator role and cannot be delegated to a staff permission. Because the create form always submits the consent block, creating a pixel needs the Administrator role as well. Staff holding the Manage pixels permission can edit an existing pixel’s name, delivery mode, catalog and purchase settings and its event mappings, and can retry a failed delivery.

How Sellerlane sends events

Each pixel has a delivery mode that controls how its events reach the destination:

• Browser only — the storefront pixel manager fires the event from the shopper’s browser using the vendor’s JavaScript tag (Meta fbq, GA4 gtag, TikTok ttq, and so on).
• Server only — Sellerlane’s backend sends the event directly to the vendor’s conversions API (Meta CAPI, GA4 Measurement Protocol, TikTok Events API, Google Ads Data Manager). Server events survive ad-blockers, browser tracking-prevention, and dropped tabs, so they are far more reliable for the events that matter most — purchases and refunds.
• Browser + server (hybrid) — both channels fire, with shared event IDs where the vendor supports deduplication so a purchase isn’t counted twice.

Which of the three a destination offers is fixed by the destination, not by you:

Destination	Browser	Server	Hybrid
Meta Pixel	Yes	Yes	Yes
TikTok Pixel	Yes	Yes	Yes
Google Analytics 4	Yes	Yes	No
Google Ads	—	Yes	—
Custom Webhook	—	Yes	—
Pinterest Tag	Yes	—	—
Microsoft UET	Yes	—	—
Snap Pixel	Yes	—	—

A new pixel starts on Browser wherever the destination has a browser tag, because that is the only mode that works before you have supplied a server credential. Google Ads and custom webhooks have no browser tag, so they start on Server. Once you save a server credential Sellerlane promotes the pixel for you — to hybrid on Meta and TikTok, to server on GA4.

GA4 refuses hybrid deliberately. Choose Server: Sellerlane still loads the gtag in tag-only mode, so the _ga client ID the server leg attributes against continues to exist.

Tip

Reach for server delivery for purchase and refund events. The seeded event map already does this: mid-funnel events (add-to-cart, checkout started, add payment info) stay browser-only, because their two legs carry unaligned event IDs and would double-count. Purchase is seeded on both channels for Meta and TikTok — both legs derive the same event ID from the order, so the destination deduplicates them.

Consent gating

Every pixel respects buyer consent before it sends anything. Under Customer privacy on each pixel, an Administrator chooses which consents are required.

The defaults depend on what the destination is for:

Destination	Analytics consent	Marketing consent
Meta, TikTok, Pinterest, Snap, Microsoft UET, Google Ads	Off	On
Google Analytics 4	On	Off
Custom Webhook	On	On

Advertising destinations are gated on marketing consent. GA4, which is measurement rather than advertising, is gated on analytics consent. A custom webhook requires both, because Sellerlane cannot classify an endpoint you declared yourself. Require sale-of-data consent is off by default everywhere.

Consent is evaluated per destination, never per event. With the defaults, a shopper who declines marketing consent is still measured in GA4, and a shopper who declines analytics consent still reaches Meta — until you change the requirements.

The storefront pixel manager re-checks consent before every browser event, so a shopper who declines marketing consent simply never triggers a marketing pixel. Server events are re-checked too: the consent snapshot taken when the event happened is narrowed to the shopper’s current consent immediately before delivery, so withdrawing consent also stops conversions that are already queued. Narrowing only ever tightens — granting consent later does not release events that were captured without it.

If a shopper hasn’t granted the consent a destination requires, a server-side event is recorded as a skipped dispatch with its reason under Analytics → Pixels. On browser delivery there is nothing to record: the tag never loads, so no row appears.

There is also a Send in-store sales (POS) purchases toggle (off by default). Enabling it sends completed POS sales to the destination as offline purchase events, and is your assertion of a legal basis to share in-store data — it replaces the web consent gate for the POS path. This option is available for Meta and GA4 destinations only, and only on a pixel whose delivery mode includes Server — POS sales have no browser to fire a tag from, so enabling the toggle on a browser-only pixel sends nothing. The sale also needs a customer email or phone on it; without one the event is skipped as pos_purchase_no_customer_identity. Meta receives those contact details hashed. GA4 has no contact vector, so it never receives them: its POS purchases carry a synthetic client ID derived from the order instead.

Caution

Turning Send in-store sales (POS) purchases back off is not a pause. It withdraws the legal basis, so POS events still waiting to be sent are skipped with the reason pos_purchases_disabled — they are not re-sent if you enable the toggle again.

Connect a pixel

1. Go to Settings → Pixels and choose Add pixel.
2. Pick a provider from the grid. Each card shows whether it supports Browser, Server, and Manual setup.
3. Under Manual setup, enter the public destination ID (and any optional server credentials).
4. Adjust the Settings — name, delivery mode, consent requirements, catalog ID strategy, purchase value, and the per-event mappings — or accept the defaults (you can change all of these later from the pixel’s detail page).
5. Choose Create pixel. You land on the pixel detail page, where you can Validate the configuration.

Note

Setup is manual for every destination except Google Ads: you paste the destination ID and any server credentials yourself. Google Ads is the exception — it is authorised through a Google sign-in, and its tokens cannot be pasted. Secrets such as access tokens are write-only: they are accepted when you save but are never read back into the UI. You can clear a stored secret from the credentials form when you need to rotate or remove it.

Meta, Google, and the rest

Meta

Provider: Meta Pixel. Enter your Meta Pixel ID. Add a CAPI access token to enable server-side events (optional for a browser-only setup, required for server events), and an optional Test event code so events show up in Meta’s Test Events tool while you verify.

GA4

Provider: Google Analytics 4. Enter your GA4 Measurement ID (format G-XXXXXXXXXX). Add a Measurement Protocol API secret to send server-side events to your GA4 web stream.

Google Ads

Provider: Google Ads. Enter your Google Ads customer ID (the 123-456-7890 value in the top-right of Google Ads) and the conversion action that should receive events — either its numeric ID or its customers/<id>/conversionActions/<id> resource name.

Creating the pixel is only the first step. A Google Ads pixel is created without a token and sends nothing until you finish the Google sign-in: open the pixel’s Credentials tab and choose Connect Google, which redirects you to Google to grant the Data Manager permission. Until that handshake completes the pixel page warns that it is not sending conversions yet.

Google Ads is server-side and uses the Data Manager events:ingest path; it fires order_paid and lead_submitted as conversions.

TikTok

Provider: TikTok Pixel. Enter your TikTok Pixel Code, an optional Events API access token for server events, and an optional Test event code.

Pinterest / Microsoft / Snap

• Pinterest Tag — enter the Pinterest Tag ID.
• Microsoft UET — enter the Microsoft UET Tag ID.
• Snap Pixel — enter the Snap Pixel ID.

These three are browser-only destinations today (their server adapters are not installed), so their events fire from the shopper’s browser and no access token is accepted. Their tag ID is also fixed at creation — there is no credentials form to edit it afterwards, so correcting a mistyped ID means deleting the pixel and creating it again.

Custom webhook pixels

Choose Custom Webhook to send sanitised server events to your own HTTPS endpoint — useful for testing your pipeline or feeding a custom data warehouse. Enter the Webhook endpoint URL and an optional Signing secret (used to sign outgoing requests so you can verify they came from Sellerlane). Custom webhooks are server-only, and because the endpoint decides where your raw event stream goes, creating and editing one is Administrator-only.

Which events fire

Out of the box each pixel is seeded with a sensible event map covering page viewed, product viewed, collection viewed, search submitted, product added to cart, add to wishlist, cart viewed, checkout started, payment info submitted, purchase (order_paid / checkout_completed), customer registered, lead submitted, and refund succeeded.

That seeded map is a starting point, not the limit. The Events editor can map any of the ~85 events the platform emits — cart_updated, variant_selected, newsletter_subscribed, fulfillment_shipped and many more — and the list is served by the platform, so it grows as new events ship. Order cancelled is one of these: it is a real event you can map, but no destination is seeded with it, so you have to add the row yourself.

Customer registered is server-only. It fires when a shopper signs in for the first time — Sellerlane accounts are passwordless, so the first verified sign-in is the registration, and a shopper whose record already existed (from a guest order or an import) counts on the sign-in that follows. Because there is no browser version of this event, it can only be delivered by a destination with an installed server adapter: Meta, TikTok, GA4, Google Ads and Custom Webhook. Meta, TikTok and GA4 seed the row for you; on Google Ads or a custom webhook you add it yourself. Pinterest, Snap and Microsoft UET cannot send it at all.

On each pixel’s Events table you control, per event:

• The provider event name it maps to (e.g. product_viewed → ViewContent for Meta, or view_item for GA4).
• Whether it sends on the Browser channel, the Server channel, or both — within what the destination supports. Both are available on Meta and TikTok; GA4 is browser or server but not both; Pinterest, Snap and Microsoft UET are browser-only; Google Ads and custom webhooks are server-only. Regardless of destination, order_paid, refund_succeeded and customer_registered stay on the server channel, because the storefront never emits them.
• Whether it’s Enabled at all.

An Add an event… picker under the table offers every event that isn’t mapped yet. A row you add needs its provider event name filled in before the form will save — leaving it blank deletes the mapping instead.

You can also tune Catalog ID strategy (Product ID, Variant ID, or SKU — match it to the item IDs in your product feed), Purchase value (total including tax and shipping, total excluding tax, subtotal after or before discounts, or amount paid), and how zero-value orders are handled.

Caution

Double counting comes from mid-funnel events — add to cart, checkout started, payment info — whose browser and server legs carry unaligned event IDs. The seeded defaults keep those browser-only; if you turn one on for both channels, the destination may count it twice. Purchase is exempt: both legs derive the same event ID from the order and only one server-side purchase per order reaches a destination, which is why the defaults ship purchase on Browser and Server together.

Test a connection and read status

From the pixels list, each row shows a Status, the Delivery mode, how many Events are enabled, and when it was Last validated. Use the row actions to keep a pixel healthy:

• Validate — re-checks the pixel’s configuration: that the destination IDs are present and well-formed. It sends nothing to the destination, so a pass does not prove events are being accepted — “Last validated” means the configuration was well-formed at that time.
• Disconnect / Reconnect — pauses or resumes a pixel without deleting its configuration. While it is paused, queued conversions are held (they show as parked) and are released when you reconnect.
• Delete — removes the pixel, its event mappings and its stored credentials. This is permanent; queued conversions are cancelled rather than held.

A pixel can be in one of these states:

Status	What it means
Connected	Enabled, the configuration passed its last check, and credentials are in place — the pixel will attempt delivery. It does not confirm the destination has accepted an event; check the dispatches for that.
Validating	A validation check is in progress.
Pending reauth	The destination rejected the stored credentials with an authorization error — re-enter them.
Error	The last configuration check failed, or the stored credentials failed their format check; the row shows that message. A failed delivery does not put a pixel in Error.
Disabled	Paused by you with Disconnect; nothing is sent, and queued conversions are held until you reconnect.
Disconnected	The destination’s connection was revoked — not a pause you made, and it needs attention.

If a pixel shows Pending reauth or Error, open it and rotate the access token or API secret on the credentials form, then Validate again. Only store Administrators can change credentials. Pinterest, Microsoft UET and Snap have no credentials form at all — to correct their tag ID, delete the pixel and create it again.

To confirm real traffic, set a Test event code (Meta / TikTok) and watch the destination’s own test tool, then check Analytics → Pixels — its Dispatches table lists each event with its status, while the Pixel runtime panel confirms whether server dispatch, browser dispatch, the dispatcher, and the worker are all registered.

A dispatch is in one of eight states: pending, sending, parked (held because the pixel is disconnected or server delivery is off), sent, failed, skipped, canceled, or dead (the retry ladder is exhausted). A Retry action is offered for failed and dead deliveries, and for events skipped because the destination’s connection was not active. Every other skip reason — consent withheld, POS purchases off, the destination repointed — is deliberate and cannot be retried.

Troubleshooting

• No events at all — confirm the pixel is Enabled and the visitor’s consent matches the pixel’s requirements. On server delivery a declined consent shows as a skip with a reason; on browser delivery the tag simply never loads, so there is no row to inspect.
• Purchases missing — purchase events are usually server-side, so make sure you supplied the server credential (CAPI token / API secret) and the destination’s delivery mode includes Server. Only an Administrator can save that credential.
• Google Ads sends nothing — check that Connect Google on the pixel’s Credentials tab has been completed. Without it the pixel exists but is never included in delivery.
• Conversions double-counted — a mid-funnel event (add to cart, checkout started, payment info) is on for both Browser and Server; restore the seeded defaults, which keep those browser-only. Purchases sent on both channels are deduplicated and are not the cause.
• POS sales not appearing — four things must all hold: the destination is Meta or GA4, Send in-store sales (POS) purchases is enabled, the pixel’s delivery mode includes Server (a POS sale has no browser to fire a tag from), and the sale carries a customer email or phone.

Next steps

Analytics & reports

See conversions and funnels in your own dashboards — pixels feed the ad platforms, while Analytics reports on Sellerlane’s own data.

Marketing attribution

Understand which channels drove each order with marketing attribution.

Marketing campaigns

Run email and automation campaigns from Marketing.

Store policies

Keep your privacy and cookie policies current to support the consent gates above.