Nimriz
Marketing and growth teams

Server-side conversion tracking

Clicking a short link is only the first event. Nimriz lets you connect clicks to leads, sales, refunds, and reversals with a signed server-side Conversion API tied to the same short link record - no client-side pixel required.

  • Server-to-server Conversion API requests - no client pixel, no third-party script dependency
  • Five core outcome types: leads, sales, refunds, cancellations, and reversals tied to the originating click
  • Works in ad-blocked, email-client, and iframe contexts where pixels fail
Start for freeAll use cases
Conversion API flow

Track what happened after the redirect without a client-side pixel dependency.

Signed API requests
1. Click
Short link redirect
Visitor clicks brand-a.to/launch
2. Conversion API
Signed server request
Your server sends outcome to Nimriz
3. Outcome
Attribution recorded
Linked to the originating click event
Outcome types
LeadSaleRefundCancellationReversal
Attribution window
Up to 30 days
Privacy posture
No client pixel needed

Client-side pixels have a reliability problem. Ad blockers remove them before they fire. Email clients never load remote tracking pixels at all. Embedded or iframe contexts block most outbound signals. The result is a gap between the clicks your short links record and the conversions your business actually cares about - leads, sales, and revenue never show up next to the campaign link that drove them.

Nimriz solves this with server-side conversion tracking. When conversion tracking is enabled on a link and the destination is safe to modify, Nimriz appends an opaque click token (nim_ct) to the destination URL. Your landing page stores the token; your server later sends a signed Conversion API request back to Nimriz when a business outcome occurs. The signed request uses an HMAC-SHA256 signature computed with your workspace conversion signing secret, so Nimriz can verify authenticity without any browser involvement.

Attribution ties the outcome back to the originating short link click, up to a 30-day window. The five supported outcome types - lead, sale, refund, cancellation, and reversal - are stored as immutable events. Negative follow-on outcomes do not overwrite the original conversion: if a sale later results in a refund, both records remain, keeping your reporting accurate and auditable.

Conversion reporting lives in the same analytics model as click data, so teams can move from "how many people clicked?" to "how many people clicked and then became customers?" without stitching together a separate attribution tool. Conversion tracking, reporting, and exports are available on supported plans.

Who it is for

Performance and growth marketers

You run paid and owned-channel campaigns and need to know which short links actually drove leads or revenue - not just clicks. Server-side conversion tracking connects your campaign links to downstream business outcomes without relying on pixels that ad blockers remove.

Lifecycle and ecommerce operators

You send transactional and promotional email, track subscription activations, and need refunds and cancellations reflected in reporting. The five immutable outcome types and the ability to record negative follow-on events mean your conversion data stays accurate through the full order lifecycle.

Technical and RevOps engineers

You own the backend funnel and need a reliable server-to-server attribution contract. The signed Conversion API gives you idempotent, HMAC-authenticated event delivery with a defined body schema, so you can instrument conversion events from any server-side environment and integrate them into your existing data workflows.

What you get

Server-side Conversion API

Your backend sends a signed request to Nimriz using a dedicated workspace signing secret when an outcome occurs. Nimriz verifies the HMAC signature to confirm authenticity, so attribution never depends on a client-side cookie or pixel match. The contract is server-to-server only: no browser SDK is required.

Five immutable outcome types

The Conversion API accepts five core outcome types: leads, sales, refunds, cancellations, and reversals. Each negative follow-on event (refund, cancellation, or reversal) is stored as a new immutable record and does not overwrite the original positive conversion. This keeps your conversion history auditable and accurate even when deals later cancel or reverse.

No client pixel required

Server-side conversion tracking works where browser pixels fail: ad blockers strip third-party scripts, email clients never load remote pixels, and embedded iframe contexts block most outbound signals. Because attribution travels from your server to Nimriz rather than from a visitor's browser, those environments do not disrupt your conversion reporting.

Per-link attribution

Every short link is its own attribution unit, so you can see which placement, channel, or campaign placement drove a lead or sale - not just which links received clicks. Conversion totals, attribution rate, and per-link outcome reporting live in the same analytics model teams already use for click data, with exports available on supported plans.

How it works

Attribution that survives the click

When an outcome occurs on your end, your server sends a signed Conversion API request to Nimriz. Attribution ties back to the originating click event on the short link - no cookie match, no third-party dependency.

1
Plan

When a visitor clicks an enabled short link, Nimriz appends a click token to the destination URL if it is safe to modify - your landing page captures and stores that token.

2
Publish

When a business outcome occurs, your server sends a signed Conversion API request including the stored click token so Nimriz can join the conversion back to the originating click.

3
Measure

Conversion reporting shows attributed outcomes per link, including attribution rate, outcome type breakdown, and variant context where an experiment or routing rule drove the click.

  • Conversion API requests are authenticated with an HMAC-SHA256 signature computed from a timestamp and the raw request body, using your workspace conversion signing secret.
  • Every request is idempotent: repeated sends with the same event ID resolve to the same business event so retries and at-least-once delivery patterns do not create duplicate conversions.
  • Refunds and reversals reference the prior sale through a related order or event ID and are stored as new immutable events - they do not edit or overwrite the original positive conversion.
Explore conversion trackingTrust and privacyFAQ
Example
1. Visitor clicks
brand-a.to/twitter-launch → example.com/signup?nim_ct=nimct_...
2. User signs up → your server sends a Conversion API request
POST https://api.nimriz.com/api/conversions/callback/:workspace_id
{ "event_name": "lead", "user_data": { "click_id": "nimct_..." }, "event_id": "crm-lead-abc123" }
3. Attribution recorded on the link
142 clicks · 18 leads · 12.7% attribution rate

Setup

  1. 1
    Enable conversion tracking on the link
    Conversion tracking is opt-in per link, not enabled by default. Open the link settings, find the Conversion tracking toggle, and enable it. When enabled, Nimriz appends nim_ct to the destination URL on each redirect where the destination is safe to modify. If the destination is signed or query-sensitive, token appending is suppressed to protect the redirect.
  2. 2
    Generate your Conversion API signing secret
    Go to Dashboard → Settings → Integrations and generate a Conversion API signing secret. This is a separate credential from your workspace API key. Store it securely in your server environment variables - it is shown only once and should never appear in browser-side code or version control.
  3. 3
    Capture the click token on your landing page
    When a visitor arrives from an enabled short link, read nim_ct from the URL query string and store it on the session, lead record, cart, or order metadata - wherever your funnel can carry it forward to the conversion event. The token is opaque and does not contain personal information.
  4. 4
    Send a signed Conversion API request from your backend
    When a business outcome occurs, your server posts a signed JSON request to https://api.nimriz.com/api/conversions/callback/:workspace_id. Include the nim_ct value as user_data.click_id, set event_name to one of lead, sale, refund, cancellation, or reversal, and sign the request with your workspace secret using HMAC-SHA256. For refunds, cancellations, and reversals, include custom_data.related_order_id referencing the original sale.
  5. 5
    Review attributed outcomes in conversion reporting
    Attributed outcomes appear in Analytics → Conversions. The view shows total conversions by type, attribution rate, conversions by link, and - where an experiment or routing rule drove the click - conversions by variant. Conversion data is also available in exports on supported plans.

What good looks like

Pixel-only attribution

  • Pixels blocked or stripped by ad blockers in most major browsers
  • Email clients never load remote tracking pixels
  • Refunds and cancellations invisible in click-level reporting
  • Attribution breaks in embedded or iframe contexts
  • No way to verify whether conversion events are authentic

Server-side conversion tracking

  • Signed server-to-server Conversion API requests bypass pixel blocking entirely
  • Works in email and embedded contexts where client scripts do not run
  • Five immutable outcome types: leads, sales, refunds, cancellations, and reversals
  • Negative follow-on events stored as new records - original conversion stays intact
  • Up to 30-day attribution window; HMAC-SHA256 signature verifies authenticity

Outcome: conversion reporting that reflects actual business results, including negative follow-on events, tied directly to the short link that drove the original click.

Frequently asked questions

Do I need a client-side pixel to use conversion tracking?

No. Nimriz conversion tracking is server-side only. Your backend sends a signed Conversion API request directly to Nimriz when an outcome occurs. No browser SDK, third-party script, or client-side pixel is required. This is intentional: it means attribution still works in ad-blocked browsers, email clients, and embedded contexts where pixels are stripped or never loaded.

What are the five outcome types and what do they cover?

The Conversion API supports five core, immutable outcome types:

  • lead - a non-monetary attributable outcome such as a form submission, trial signup, demo booking, or newsletter subscription.
  • sale - a confirmed purchase, paid invoice, or subscription activation. Supports monetary value, currency, and order identifiers.
  • refund - a confirmed refund on a prior sale. Must reference the original sale via related_order_id or related_event_id.
  • cancellation - a cancellation or void of a prior commitment when your billing system distinguishes it from a refund.
  • reversal - a chargeback or negative financial adjustment when it does not fit refund or cancellation semantics.
How do refunds and cancellations affect the original conversion?

They do not overwrite it. Refund, cancellation, and reversal events are stored as new immutable records. The original positive conversion (lead or sale) remains in your reporting history. Negative follow-on events must reference the prior sale through custom_data.related_order_id or custom_data.related_event_id. This design keeps your conversion history auditable even when deals cancel or reverse after the fact.

How does the click token and signing model work?

When conversion tracking is enabled on a link and the destination is safe to modify, Nimriz appends an opaque click token (nim_ct) to the destination URL at redirect time. Your landing page reads and stores this token. When a business outcome occurs, your server includes the token as user_data.click_id in the Conversion API request. The request must be signed with an HMAC-SHA256 signature computed from your workspace conversion signing secret and the raw request body, combined with a Unix timestamp for replay protection. Nimriz verifies the signature before recording the event.

What happens if the destination URL is signed or query-sensitive?

Nimriz suppresses click-token appending rather than risk breaking the redirect. Common examples include pre-signed S3 or GCS URLs containing X-Amz-Signature, X-Goog-Signature, or policy parameters, and payment confirmation URLs with integrity tokens. The link still redirects normally - it just does so without the nim_ct parameter. You can still send conversion events using user_data.external_id to link outcomes to customers identified by your own system.

Is conversion tracking available on all plans?

Conversion tracking, conversion reporting, and exports are available on supported plans. Each surface requires both a plan entitlement and its matching account rollout flag. Check the pricing page or your workspace settings to confirm which surfaces are active for your account.

What happens if I send the same conversion event more than once?

The Conversion API is idempotent. If you send a request with the same event_id more than once, Nimriz returns the stored result rather than creating a duplicate business event. This makes it safe to retry failed requests. Use a stable event_id that identifies the specific business outcome (for example, your CRM lead ID or order ID), and generate a fresh Idempotency-Key header on each retry attempt for transport-level protection.

Does conversion reporting preserve experiment and routing context?

Yes. When an experiment or routing rule drove the click, conversion reporting can preserve the routed variant context. The Conversions view in Analytics includes a conversions-by-variant breakdown for A/B-routed links. Reporting also preserves click-time campaign context such as UTM values and tags where Nimriz captured them at click time.

Related use cases

Campaign links
The click-side foundation for conversion tracking.
Ad retargeting and conversion APIs
Combine server-side attribution with retargeting audiences.
Analytics integration
Route conversion data alongside your broader analytics stack.

Deeper reading

Conversion tracking feature overviewConversion tracking setup guideAPI referenceGlossary: server-side conversion trackingGlossary: conversion APIBlog: building a complete attribution stack

Ready to get started?

Create your account and start with the Starter workflow. Compare plans when you need higher limits or supported-plan capabilities.

Start for freeView pricing