Klaviyo Link Tracking: Short Link Clicks as a Custom Metric

Klaviyo link tracking through Elido is server-side and runs one way: every click on one of your short links is posted to Klaviyo's Events API as an event on a custom metric called Elido Link Click. The event carries the link slug and ID, the country and device, the destination the visitor was sent to, and the click time. The metric is created on first use, and you can chart it, filter it and build reports on it like any other.

What it doesn't do is put the click on a subscriber's profile. Each event is keyed to the link through an anonymous ID, so a link clicked by 4,000 people shows up in Klaviyo as one anonymous profile with 4,000 events on its timeline. That single fact decides what the integration is good for. I'll walk through the payload, the setup, what flows and segments can do with it, and how it compares with Klaviyo's native click tracking.

If your links aren't tagged consistently yet, fix that first. The cornerstone on tracking UTMs end to end covers the convention, and Klaviyo only ever sees what the link carries.

What Elido Sends to Klaviyo on Every Click

One click, one POST. The forwarder calls https://a.klaviyo.com/api/events/ with your private key in the Authorization: Klaviyo-API-Key header and a revision: 2023-02-22 header. This is the endpoint documented in Klaviyo's Create Event reference.

Here's the full body, with example values:

{
  "data": {
    "type": "event",
    "attributes": {
      "time": "2026-09-21T09:14:22Z",
      "properties": {
        "workspace_id": 12,
        "link_id": 4711,
        "slug": "autumn-drop",
        "country": "DE",
        "device": "mobile",
        "destination": "https://shop.example/autumn?utm_source=instagram",
        "ip": "203.0.113.24"
      },
      "metric": {
        "data": {
          "type": "metric",
          "attributes": { "name": "Elido Link Click" }
        }
      },
      "profile": {
        "data": {
          "type": "profile",
          "attributes": { "anonymous_id": "elido-link-4711" }
        }
      }
    }
  }
}

That's all of it. No email, no phone number, no UTM fields as separate properties, no referrer and no browser.

A few details matter once you start filtering. destination is the URL this visitor actually got, after any smart link routing rules, so a link that sends iPhones to the App Store and everyone else to your shop produces two destination values. device is one of mobile, tablet or desktop. UTM tags only exist inside the destination string, so filtering on utm_campaign directly isn't possible; filter on slug instead, which is usually the cleaner key anyway.

Crawlers that announce themselves in their user agent are dropped at the redirect and never forwarded. Clicks that Elido's own heuristics flag as suspicious are still sent, and the event has no property saying so.

One Anonymous Profile per Link, and Why

Every Klaviyo event has to name a profile, identified by an email, a phone number, an external ID, a Klaviyo ID or an anonymous_id. Elido always sends the last one, built as elido-link- plus the link ID.

So every click on autumn-drop goes to the same profile. The first click creates it, and every later one is appended to its timeline.

This has three consequences, and the third one surprised me.

First, counts work and people are unknown. Total clicks, clicks per link, per country and per device all work. "Unique" anything counts links, not humans.

Second, the anonymous profile has no email or phone. It can sit in a segment, but it can't receive a message.

Third, same-second clicks collapse. The forwarder sends no unique_id, and Klaviyo's reference says that without one it deduplicates on the event time to the second, for the same profile and metric. Since the profile is per link, two people clicking the same link inside the same second become one event. For a newsletter link that trickles in, you'll never notice. For a link in a big Instagram story, where clicks arrive several per second at the peak, the Klaviyo count will run below the count in your Elido click analytics. The upside: the forwarder's one retry can't double-count, because a retried event has the same time.

Why not a per-visitor ID? The redirect doesn't know who the visitor is, and I'd rather it didn't drop a cookie on a domain the visitor never chose to visit. It's the same trade-off we made for Mixpanel link tracking, where distinct_id is per link for the same reason.

Setting Up Klaviyo Link Tracking in Elido

The setup is one field.

1. In Klaviyo, go to Settings, then API keys, and create a private API key. The Create Event reference lists events:write as the scope it needs. Elido's in-app setup notes also mention profiles:write; I'd start with events only and add the second if Klaviyo returns 403s.
2. In your Elido workspace, open Integrations, pick the Klaviyo card and click Connect Klaviyo.
3. Paste the key into Private API Key and save. Elido encrypts it at rest and only ever shows it masked afterwards.
4. Wait about five minutes. Integration settings are cached on the forwarding side, so the first clicks after saving may not be sent.
5. Click one of your own links from a phone, then open Analytics > Metrics in Klaviyo and look for Elido Link Click.

The Test connection button posts one test event (marked elido_test: true) to Klaviyo and shows Klaviyo's answer, so a revoked or read-only key fails right there. It proves the key works, not that the metric lands on the profile you expect. The metric appearing in Klaviyo after a real click is the proof.

There's no per-link switch. Every click in the workspace is forwarded, including links you never meant for marketing. Agencies running many clients should give each client its own workspace before connecting anything.

Klaviyo Native Click Tracking vs the Elido Metric

Klaviyo already tracks clicks in its own emails and texts, and for subscriber-level work that native tracking wins. It rewrites every link through its tracking domain, records Clicked Email or Clicked SMS on the recipient's profile, and marks likely scanners with a Bot Click property you can exclude from reporting.

Where Elido's metric earns its place is everywhere else: the link in your Instagram bio, a QR code on packaging, a link a partner sends from their own newsletter, a link in a podcast show note. None of those clicks pass through Klaviyo's tracker. With the forwarder on, they show up in the same account as your email metrics, so one Klaviyo dashboard can put "clicked the autumn link from anywhere" next to "clicked the autumn email".

One interaction to watch. In live emails, Klaviyo appends a _kx parameter to every link so that its onsite script can identify the clicker on your website. If the link in your email is an Elido short link, _kx lands on the short URL, and Elido's redirect doesn't carry incoming query parameters over to the destination. The onsite identification is lost. My rule: inside Klaviyo emails, link straight to your own site and let Klaviyo track it; use short links for the channels Klaviyo can't reach.

Getting Clicks onto Real Subscriber Profiles

Sometimes you do want the click on a person. There are two ways that work today, and neither of them is the forwarder.

The easy one is to let Klaviyo's onsite tracking do identity. Send the shared short link to a destination with UTM tags, and make sure Klaviyo's JavaScript runs on that page. Visitors who are already cookied from an earlier email click, or who sign up through a form, get their onsite activity attached to their profile. The short link click stays anonymous; the visit after it doesn't. You then compare the two at campaign level, which is coarser than per person, but it's honest about what each side knows.

The heavier one is per-recipient links. For a small, high-value list, such as a B2B sequence or VIP invites, create one short link per person through the API at /v1/workspaces/{workspace_id}/links and keep your own table of link ID to email. Subscribe to link events over webhooks, look up the email when a click arrives, and post your own event to Klaviyo with that email as the profile identifier. It's maybe forty lines of code, and it's the only route that puts an Elido click on a named subscriber. I wouldn't do it for a 200,000-person newsletter.

If mixed-channel click counts inside Klaviyo are what you've been missing, pick a plan and connect a workspace, then point your next social campaign through branded links.

Limits of the Forwarder Today

Five things to know before a report depends on it.

Delivery is best effort. A failed POST is retried once after a second, then dropped, and nothing is queued for later.

The Events API is rate-limited per account, at 350 requests a second in bursts and 3,500 a minute steady. That budget is shared with every other app writing events to your account. A campaign spike above roughly 58 clicks a second, sustained for a minute, will see 429s, and after the one retry those clicks are gone from Klaviyo.

The revision header is old. Klaviyo gives each API revision two years before retirement, and requests to a retired revision are served by the next oldest available one. The 2023-02-22 revision is past that line, so today the forwarder works through fall-forward. It does work. I'd still like the header bumped.

The visitor IP is sent as an event property. Expect it to be stored like any other property, so treat it as personal data in your records of processing. The EU data residency guide for marketing teams covers how to weigh that.

Clicks only. Conversions aren't part of the payload, so track revenue where the customer identity lives, which for most shops is Klaviyo's own ecommerce integration.

Related on the Blog

• Track UTMs end to end - the tagging convention the campaign-level join depends on.
• Mixpanel link tracking - the same forwarder pattern, with the same per-link identity.
• Webhooks for link events - the building block for per-recipient click events.
• Email click attribution for Mailchimp, Brevo and Klaviyo - the wider view across email platforms.
• Short-link clicks vs GA4 sessions - why click counts and analytics sessions never match.
• Datadog URL monitoring - the same click forwarder, feeding a Datadog dashboard.