Skip to main content

​
Link routes

Links inside notifications are first-class citizens — Notifizz tracks the click and (optionally) routes through a redirect for analytics, attribution, or short-link replacement. This page covers the link-route concept and its tracking semantics.

​
TL;DR

  • Every clickable link in a notification is wrapped in a Notifizz redirect (per-message id).
  • The redirect records the click event, then redirects to your destination URL.
  • Click attribution flows into the campaign’s funnel — Delivery → Read → Opened → Clicked.
  • UTM parameters can be added at the campaign level or hard-coded in the link itself.

​
How it works

Each link in your template renders as a Notifizz redirect URL when the message is created. The redirect carries an opaque routeId that ties back to:
  • The message id (for delivery-level attribution).
  • The recipient id.
  • The original destination URL.
When the user clicks, Notifizz records the click event (visible in the campaign’s funnel) and then 302s to the destination.

​
Setup

The dashboard’s template editor handles link routes transparently:
1

Insert a link in the template

Use the editor’s “Link” toolbar button or the rich-text shortcut. Paste your destination URL.
2

Configure tracking

By default every link is tracked. Toggle off per-link if you want a raw mailto: or tel: URL with no Notifizz redirect.
3

Variables in URLs

Use {{ variable.name }} inside the URL — the editor resolves at send time. For example, https://app.example.com/orders/{{ event.orderId }}.
For NC messages, the widget intercepts clicks and posts to POST /v1/notification/event/register with eventType: "clicked" directly — no redirect chain on the user’s browser. For email, the destination URL is rewritten at render time to point at the Notifizz redirect; the redirect handles the click event server-side.

​
Tracking semantics

StepWhen it firesCounts toward
sendBackend delivered the message (NC) or accepted it for delivery (email)Delivery counter
readThe user saw the message in the dropdown / preview paneRead funnel
openedThe user clicked into the message detail (NC) or the tracking pixel fetched (email)Opened funnel
clickedA link inside the message was followedClicked funnel
Each event is keyed by (messageId, eventType) — duplicates dedupe. A user who clicks twice doesn’t double-count. If you have a link you don’t want tracked (e.g. a mailto: that doesn’t make sense to redirect), toggle tracking off in the editor. The link renders as a raw URL with no Notifizz wrapping. 
<!-- Tracked -->
<a href="https://app.example.com/orders/{{ orderId }}">View order</a>

<!-- Untracked (raw) -->
<a href="mailto:support@example.com">Email support</a>

​
UTM parameters

Two patterns:

​
Hard-code per template

<a href="https://app.example.com/orders/{{ orderId }}?utm_source=notifizz&utm_campaign=order-shipped">View order</a>
The redirect appends nothing; UTM lands at your destination. Use this when UTM tagging is per-template.

​
Inject at the campaign level

The campaign config can declare UTM parameters that the redirect appends to every destination URL automatically. Use this when UTM tagging is per-campaign and the templates shouldn’t repeat the boilerplate. The exact UI is in the campaign settings → Link tracking section.

​
A/B testing two URLs

Branch in the orchestrator: 
const variant = Math.random() < 0.5 ? "A" : "B";
return [{
  id: user.id,
  email: user.email,
  ctaUrl: variant === "A" ? "/checkout" : "/checkout-v2",
  variant,
}];
Then reference {{ recipient.ctaUrl }} and {{ recipient.variant }} in the template. The funnel splits by variant if you wire the campaign’s branching schema. For full A/B testing infrastructure (statistical significance, automatic variant pickup), the campaign editor exposes a dedicated experimentation surface — the “branch in orchestrator” pattern is the manual fallback.

​
Security

The redirect is open by design (302 to any URL), but Notifizz prevents some classes of abuse:
  • Domain allow-list per organisation — optional. The dashboard can restrict redirects to a configured allow-list. Useful for orgs with strict open-redirect policy.
  • Signed redirect IDs — the routeId is opaque and tied to the message; you can’t construct a redirect URL externally that bypasses tracking.
  • Per-recipient tokens — the routeId references the message-recipient pair; another user’s routeId lands on the same destination but the click is recorded against the original recipient.
The default redirect URL is https://eu.api.notifizz.com/v1/redirect/<routeId>. For branded short links, configure a custom domain (e.g. https://l.example.com/<routeId>) — DNS CNAME + dashboard settings. The destination resolution and tracking are identical; only the visible host changes.

​
FAQ

Campaign settings → Link tracking → “Append UTM” section. The configured parameters are appended to every tracked link’s destination at render time. Per-template overrides win when both are set.
Two suspects: (1) tracking is toggled off for that specific link in the editor; (2) the link is in a section the user never sees (collapsed accordion, mobile-hidden). Check the funnel — if “opened” fires but “clicked” doesn’t, suspect (2).
Three layers: (1) the redirect ID is opaque and message-bound — you can’t construct one externally; (2) Notifizz can be configured to allow-list destination domains per organisation; (3) the click event includes the user identity, so abuse is auditable. Combined, these make Notifizz redirects unattractive for phishing — the destination is bound at message creation time, not at click time.

​
See also

Channels (detail)

Per-channel dispatch internals.

Brands and variables

{{ }} resolution at template-render time.

Delivery history & stats

The funnel (Delivery → Read → Opened → Clicked).

Observability

Tracing one click through to the destination.