Click to Messenger Links: m.me Links With Tracking

A click-to-Messenger link is an m.me web address that opens a Facebook Messenger chat with your Page when tapped. The format is https://m.me/YourPage, and adding ?ref=payload attaches a tracking tag. Tap the link, Messenger opens at a conversation with your business, and the ref value is handed to your app.

That last part is the difference between Messenger and WhatsApp. A wa.me link opens the chat and tells you nothing about where the tap came from. Messenger's ?ref= parameter is delivered to your webhook when the conversation starts or resumes, so the attribution most messaging deep links throw away is built into the link here. For placements without a bot, and to record the click itself, you still put a redirect in front. This post covers both halves.

The m.me URL Pattern

There is one address and one parameter that matters. Meta documents it in the m.me links reference (accessed 2026-07-18).

• Open a chat with your Page: https://m.me/YourPage, where YourPage is the Page's public username, not its numeric ID. Set the username in Page settings first, or the link will not resolve.
• Attach a tracking tag: https://m.me/YourPage?ref=spring-promo. The ref value is URL-safe text that rides along and is delivered to your app.

The username requirement trips people up. A Page without a claimed username has no working m.me link, so this is the first thing to check. Once the username is set, the base link works immediately, and the ref parameter is optional sugar on top that turns a plain chat opener into a measurable one.

Opening an m.me link also resets the standard 24-hour messaging window, which is the period Meta allows your Page to reply freely after a user interacts. That matters for any follow-up automation, and it is another reason the click-to-Messenger link is more than a convenience shortcut.

Why the ref Parameter Is the Attribution Win

Most click-to-chat channels are one-way: the tap opens the conversation and you never learn what drove it. Messenger breaks that because ?ref= comes back to you. Meta delivers it through a messaging_referrals webhook (accessed 2026-07-18) for an existing conversation, and inside a messaging_postbacks event when a new conversation starts on the Get Started tap.

So the payload can carry a campaign id, a placement name, or an encoded record id, and your app reads it the moment the chat begins. No pixel, no guessing from the message text. The ref from m.me/YourPage?ref=ig-bio arrives in the webhook, and you know the conversation started from the Instagram bio link rather than the homepage.

This is the mirror image of the WhatsApp problem. The WhatsApp click-to-chat guide has to smuggle a tracking id into the prefilled message body because wa.me reports nothing back. Messenger hands you a clean channel for the same signal. Telegram does something similar with its bot start parameter, covered in Telegram deep links. Among the big three, WhatsApp is the odd one out.

The Redirect Layer

The ref webhook is powerful, but it only fires if you have an app and a webhook wired up, and it only tells you about conversations, not raw taps. For everything else, put a short link in front of the m.me URL. The customer taps s.elido.me/msg, the edge records the click, then redirects to https://m.me/YourPage?ref=ig-bio.

From your side, three things change:

• The click is recorded. The redirect fires an event with time, geo, device, and the UTM parameters on the short link, so even a placement with no webhook is measured.
• The destination is editable. Swap the Page, the ref payload, or the whole destination without reprinting a QR or editing a live ad. Move a campaign to a different Page and you change it once.
• The campaign data is portable. s.elido.me/msg?utm_source=ig&utm_medium=bio&utm_campaign=spring captures the tags at the redirect, joinable later to the conversation the ref webhook reported.

The short link and the ref parameter are not competing, they layer. The redirect gives you the click and the UTM context; the ref gives you the in-conversation confirmation. Together they close the loop from ad impression to chat. This is the same redirect layer described in tracking UTM end to end.

If you would rather not build the redirect and webhook plumbing yourself, Elido's deep links sit in front of any m.me destination and log every tap, and you can set one up on the free plan.

Click-to-Messenger Ads

If you run Meta ads with Messenger as the destination, the ad platform passes a ref through to the conversation automatically, and that attribution lands in Ads Manager. You do not need to hand-build the link for the paid case; the ad objective handles it.

Where the manual link and the short-link layer earn their keep is organic and offline: the Instagram bio, the email footer, the printed QR, the website button. Those placements have no ad platform behind them, so the ref you set plus the click the redirect records are the only attribution you get. Treat paid Click-to-Messenger and organic click-to-chat as two tracks that both feed the same Messenger conversion picture.

A Practical Setup

Three short links cover most Pages:

• General link: s.elido.me/msg to your main Page, used in the website footer, the bio, and the email signature. Its ref names the surface, like ref=site-footer.
• Campaign link: one per active campaign, s.elido.me/msg-spring, with a campaign-specific ref so the webhook and the click both carry the tag.
• QR-printed link: s.elido.me/msg-shop for physical placements, with a ref that names the placement so the conversation opens already labelled.

Each link maps to a UTM template and a descriptive label like surface:ig-bio · channel:messenger · campaign:spring. Configure them at /links and the labels drive the filters in analytics. Filter by channel:messenger to see every Messenger-driven tap across campaigns.

QR Code Surfaces

A real share of click-to-Messenger traffic comes from scans in a physical context: a shop, an event, a flyer. Print-to-conversation is one of the strongest uses of the short-link-then-m.me pattern.

Two rules keep the print run useful:

• The QR encodes s.elido.me/<slug>, never m.me/... directly. Encoding m.me locks the destination, kills the scan analytics, and wastes the print run if the Page username changes.
• Each placement gets its own short link and its own ref, so the window code, the flyer code, and the packaging code are separate rows you can compare. Quiet zone, contrast, and error correction are the usual concerns, covered in dynamic vs static QR codes.

What Does Not Work

Three patterns that look reasonable and fall over:

Encoding the raw m.me link in a QR or ad. No click data, no destination control, and a dead asset the moment the Page username changes. Print the short link, always.

Setting a ref with no webhook to receive it. The ref value is only useful if an app is listening for the referral event. Without a handler, the tag is delivered to nothing. If you have no bot yet, lean on the short link for the click and add the webhook when you build the automation.

Overlong or unsafe ref values. Keep the ref short and URL-safe. Stuffing a full UTM string or spaces into it invites truncation and encoding bugs. Use a compact id and resolve it to the campaign details on your side.

Messenger is the friendliest of the click-to-chat channels for attribution, because the link itself carries a tag that comes home. Pair the ref with a short link in front, and you get both the tap and the conversation, joined to the campaign that started them.

Related on the Blog

• WhatsApp click-to-chat links with tracking
• Telegram deep links: track t.me and bot start links
• What is a deep link, and how it differs from a normal link
• Tracking UTM end to end with short links
• Smart links explained: one link, many destinations