---
title: "Tracking Overview - Serpwise Documentation"
description: "How Serpwise Tracking captures first-party analytics, defines conversion events, forwards server-side deliveries, and debugs failures from the gateway."
url: "https://serpwise.ai/docs/conversion-tracking/"
source: "https://serpwise.ai/docs/conversion-tracking/"
---
[Back to Serpwise](/)

Serpwise Documentation

Connect · Configure · Execute

Search documentation

`/`

No documentation found.

↑↓ Navigate Enter to open

Browse documentation

Serpwise Tracking is the product area for measurement at the edge. It combines first-party GTM / GA4 script proxying, optional Google tracking injection, server-side conversion definitions, ad-platform integrations, event logging, replay, quality scoring, live debugging, and AI-attribution pixel goals.

Tracking runs in the gateway request path. That matters because the gateway can see the request, response, cookies, bot classification, AI attribution context, and configured rules before the browser or ad blocker gets a vote.

## Product Model

| Area              | What it does                                                                                                                     | Dashboard location              |
|-------------------|----------------------------------------------------------------------------------------------------------------------------------|---------------------------------|
| **Integrations**  | Stores encrypted destination credentials for Meta, TikTok, Google Ads, GA4, Snapchat, Pinterest, Twitter/X, and webhooks.        | **Tracking > Integrations**  |
| **Conversions**   | Defines what counts as a conversion, when it fires, where it is sent, and how often it is counted.                               | **Tracking > Conversions**   |
| **Event Log**     | Persists every delivery row with platform, status, response, source URL, value, currency, order ID, revisions, and replay state. | **Tracking > Event Log**     |
| **Live Debugger** | Streams gateway events in real time while you test setup and payload quality.                                                    | **Tracking > Live Debugger** |
| **Settings**      | Controls GTM / GA4 script proxying and optional Google tracking injection.                                                       | **Tracking > Settings**      |
| **Quality**       | Shows match-quality coverage and improvement recommendations when enabled.                                                       | **Tracking > Quality**       |

## How Events Flow

```
Visitor request
  -> Serpwise gateway resolves the domain
  -> Request is logged with bot, session, AI source, and URL context
  -> Enabled conversion definitions are evaluated
  -> Legacy fire_conversion_event rule actions are evaluated
  -> Event data is extracted from request, response, cookies, or server ingest
  -> Consent, bot filtering, transforms, and dedupe run
  -> Event is queued for platform delivery
  -> Event Log records pending, success, failed, or deduplicated status
  -> Live Debugger streams the processing result
```

Conversion definitions and legacy `fire_conversion_event` rules are evaluated from the request logging path. This keeps conversion firing independent from HTML cache behavior: a cache hit can still log the request and evaluate tracking.

## What Can Trigger a Conversion

### Conversion Definitions

Use **Tracking > Conversions** for the normal workflow. A conversion definition has:

- **Name and event name**: for example `Purchase`, `Lead`, or `AddToCart`.
- **Conditions**: the same request-condition shape used by the rules engine.
- **Extraction**: where to find value, currency, order ID, content IDs, and identity fields.
- **Targets**: destination integrations plus optional per-platform event-name overrides.
- **Counting mode**: count every match or cap repeat conversions per visitor within a dedupe window.
- **Priority**: controls evaluation order when multiple definitions could match.

Funnels are also modeled in the Conversions area. Event-style conversions fire live in the gateway; funnel reports are reconstructed from request-log session streams.

### Legacy Rule Action

Advanced rule-builder workflows can still use the lower-level `fire_conversion_event` action. This is useful when a conversion should live beside other rule actions, but new setup should generally use **Tracking > Conversions** because it is easier to audit and explain.

### Server-to-Server Ingest

External systems can POST conversion events to the gateway endpoint:

```
POST /tracking/ingest
```

This is a server-to-server endpoint protected by `X-Internal-Key`. It accepts up to 100 events and a 1 MB body. See [Tracking Ingest API](/docs/tracking-api).

### First-Party AI Attribution Pixel

AI Attribution uses a separate first-party pixel endpoint:

```
POST /api/conversions/{domainId}
```

That endpoint records pixel-originated conversion rows with `platform = pixel` so AI-attributed visits can be stitched to goals and revenue. It is not the same as the ad-platform ingest endpoint.

## Script Proxy and Injection

The GTM / GA4 script proxy rewrites known Google tracking URLs in HTML responses:

| Original                                        | First-party path     |
|-------------------------------------------------|----------------------|
| `https://www.googletagmanager.com/gtm.js`       | `/sw-t/gtm.js`       |
| `https://www.googletagmanager.com/gtag/js`      | `/sw-t/gtag/js`      |
| `https://www.google-analytics.com/analytics.js` | `/sw-t/analytics.js` |
| `https://www.google-analytics.com/g/collect`    | `/sw-t/g/collect`    |

The exact prefix is configurable in **Tracking > Settings**. `/sw-t` is the default.

If a site does not already have Google tracking, Serpwise can inject GA4 and/or GTM bootstraps. The `onlyIfMissing` guard prevents double-loading when the origin already has Google tracking.

See [GTM / GA4 Script Proxy](/docs/script-proxy).

## Delivery Pipeline

1. **Match**: the gateway checks enabled conversion definitions and legacy conversion rules.
2. **Extract**: event fields are pulled from selectors, regex, request body, cookies, JSON-LD, Open Graph, or ingest payloads.
3. **Filter**: known bots and headless clients are excluded from real conversion forwarding.
4. **Consent**: integrations can require analytics, marketing, or personalization consent.
5. **Transform**: per-integration rules can rename, drop, set fields, or route events.
6. **Dedupe**: order IDs, visitor/session windows, database uniqueness, and platform event IDs prevent duplicate deliveries.
7. **Forward**: credentials are decrypted on demand, PII is hashed, and events are sent through platform clients.
8. **Observe**: Event Log and Live Debugger show results, errors, duration, retries, and replay status.

## Supported Destinations

| Platform       | API                  | Credentials                                                                      |
|----------------|----------------------|----------------------------------------------------------------------------------|
| **Meta**       | Conversions API      | Access token, Pixel ID, optional Test Event Code                                 |
| **TikTok**     | Events API           | Access token, Pixel Code                                                         |
| **Google Ads** | Enhanced Conversions | Customer ID, Conversion Action ID, OAuth refresh token, client ID, client secret |
| **GA4**        | Measurement Protocol | Measurement ID, API secret                                                       |
| **Snapchat**   | Conversions API      | Access token, Snap Pixel ID                                                      |
| **Pinterest**  | Conversions API      | Access token, Ad Account ID                                                      |
| **Twitter/X**  | Conversions API      | Access token, Pixel ID                                                           |
| **Webhook**    | Custom HTTP          | Endpoint URL, method, headers, body template                                     |

## Consent Management

When consent requirements are enabled on an integration, the gateway forwards events only when the required categories are present.

Supported sources:

- **OneTrust**: `OptanonConsent` cookie
- **Cookiebot**: `CookieConsent` cookie
- **Custom**: `_sw_consent` cookie with comma-separated categories such as `analytics,marketing`

Events without required consent are logged as `consent_denied` in the debugger stream and are not forwarded.

## Monitoring and Replay

Use **Tracking > Event Log** to inspect persisted rows. You can filter by platform, status, event type, and integration; export rows; open an event detail sheet; edit payload revisions; and replay failed deliveries.

Use **Tracking > Live Debugger** while setting up a conversion. It streams forwarded, failed, deduplicated, consent-denied, and dropped events without waiting for a later report.

Use **Tracking > Conversions > Analytics** for performance reporting: conversion volume, success rate, revenue, platform comparison, event types, top converting pages, conversion rate by page, page views, and integration health.

## Next Steps

[**Tracking Integrations**  
→  
\
Connect destination credentials and configure consent requirements.](/docs/tracking-integrations)

[**Tracking Events**  
→  
\
Create conversions, configure extraction, route targets, and monitor delivery.](/docs/tracking-events)

[**GTM / GA4 Script Proxy**  
→  
\
Rewrite Google tracking through your first-party domain.](/docs/script-proxy)

[**Tracking Ingest API**  
→  
\
Send server-to-server conversion events into the gateway.](/docs/tracking-api)

[**Live Event Debugger**  
→  
\
Watch events flow in real time during setup and troubleshooting.](/docs/tracking-debugger)