Most traffic reports fail in the same spot. They show a chart of "sources" without explaining that it's built from two very different signals: a referrer header the visitor's browser volunteers, and UTM parameters you attach to the link yourself. You control one of those completely. The other gets stripped, blocked, or lost far more often than most dashboards let on, and that gap is basically what this whole page is about: the data you can trust is the data you put there yourself.
Find the traffic source or acquisition report
Every analytics tool ships a report built for exactly this question, and it is rarely the first screen you land on. In Google Analytics 4 it is under Reports, Acquisition, Traffic acquisition. In Shopify it is Analytics, Reports, Sessions by traffic source. In a link tracking tool like Raydar, it is the per link click detail, which breaks a single short link down by referrer, UTM tag and click ID rather than mixing it into whole site totals. Open the report built for the question before trying to reconstruct the answer from a plain pageviews graph, which was never designed to answer it.
Understand what source, medium and channel actually mean
Once the report is open, the labels matter more than the numbers. Source is where the visit came from: instagram.com, google, a newsletter tool. Medium is the category that source falls into, like social, organic, email or cpc. Channel is different again, a rollup each tool builds from source and medium using its own rules, and because every tool's rules differ slightly, the same traffic can land as "Social" in one tool and "Referral" in another. Read source and medium first, and treat channel as a shortcut the tool built for you rather than ground truth.
Tag every link you post with UTM parameters
Referrer headers are the weakest link in the chain. Instagram, TikTok and Facebook's in app browsers frequently pass no usable referrer at all, and neither do most native mobile apps, so a click that genuinely came from an Instagram story can land in analytics as direct or unassigned with nothing pointing back to the post that sent it. UTM parameters solve this because they travel inside the URL itself instead of depending on what the browser chooses to disclose, and they survive the in app browsers that swallow referrer data completely. Build the tag before you post the link, not after: a UTM builder handles the formatting so utm_source, utm_medium and utm_campaign land in the report as clean, comparable values instead of five spellings of the same campaign. If the parameters themselves are new to you, what UTM parameters are and how source and medium differ are worth five minutes before your first tag.
Check click level data from your link in bio or shortener tool
Whole site analytics tell you a session started somewhere. They rarely tell you which specific post, story or email drove it, because that level of detail depends on the link itself, not just the site it lands on. A link tracking tool sits at the layer where that detail still exists: it sees the click before the redirect, so it can log the referrer, the UTM tag and often a click ID all at once, then hand off to your destination page. Raydar's click analytics work this way, and because they capture first touch and last touch separately, they can tell you both what originally brought someone into your audience and what sent them back this time, which a single touch site report cannot.
Use click IDs to confirm ad platform traffic
Paid clicks carry their own fingerprint. Google Ads appends gclid, Meta appends fbclid, TikTok appends ttclid, and Microsoft Ads appends msclkid, automatically, whether or not you added UTMs. These click IDs are useful confirmation even when UTMs are present, because they prove the click actually originated inside the ad platform's redirect rather than from someone copying a link that happens to carry a matching UTM tag. If a "paid social" row in your report looks too high or too low, checking for the matching click ID is a faster sanity check than re auditing every campaign.
Deal with what's left over: direct and unassigned traffic
After UTMs and click IDs are accounted for, some traffic will still land in a direct or unassigned bucket, and that is normal, not a sign the report is broken. It usually means the referrer was stripped somewhere between the click and the page load, most often by an in app browser, an email client, or a link pasted into a messaging app rather than clicked from a post. There's no setting to flip here. Tagging more links before you share them is the actual fix, since a well formed UTM survives conditions a referrer header does not. Why traffic shows as direct covers the specific causes and which ones you can actually fix.
Traffic source signals compared
Not every signal a report relies on is equally trustworthy, and it helps to know what each one is actually made of.
| Signal | Who sets it | Survives in app browsers | Survives redirects | What it proves |
|---|---|---|---|---|
| UTM parameters | You, in the link | Yes | Yes, if the redirect preserves query strings | Which specific post or campaign the click came from |
| Referrer header | The visitor's browser | Often stripped | Often dropped across redirects | Roughly where the visit originated, when present |
| Click ID (fbclid, gclid, ttclid) | The ad platform | Yes | Yes | That the click came from a real ad click, not a pasted link |
| IP and geo data | The network request | Yes | Yes | Approximate country and city, not a source |
The pattern in that table isn't subtle: the signal you control is the one that survives. Referrer data is genuinely useful when it shows up, but plan your reporting around UTMs and click IDs, and treat referrer as a bonus rather than the foundation.
A quick example
Say a story link on Instagram gets forty clicks. Ten arrive with a clean referrer from instagram.com. Twenty two arrive with no referrer at all, because the person opened the link inside Instagram's in app browser, which strips it. Eight arrive from people who screenshotted the story and texted the link to a friend, so there was never a referrer to strip in the first place. Without UTMs, an analytics tool sees ten "Instagram" visits and thirty "direct" visits, and a marketer might reasonably conclude the post underperformed. With a utm_source=instagram tag on the link, all forty show up correctly, because the tag does not depend on what the browser is willing to disclose.
This is also where link in bio analytics earn their keep for creators running most of their traffic through a single bio link: every click passes through one tracked redirect first, so source data gets captured before an in app browser has the chance to swallow it.
What platform-native analytics can and cannot tell you
Instagram's professional account insights show real numbers: tap counts on your bio link, story link taps, profile visits, all inside Instagram's own dashboard. TikTok's analytics show a similar profile and bio link click count. These figures are genuine and worth a quick glance, but they stop at the platform's edge. Instagram can tell you the link on your profile was tapped forty times this week. It cannot tell you whether those forty taps became a real page visit, a bounce, or a sale, because Instagram has no visibility past the moment someone leaves its app.
This is the gap a link tracking tool is built to close. Once a click passes through a tracked redirect, it carries a referrer, a UTM tag and often a click ID into your own analytics, so the platform's tap count and your site's traffic source report can finally be compared side by side instead of living in two dashboards that never talk to each other. It also means the number you report to a client or a manager comes from a system you control, rather than a screenshot of someone else's app.
A short checklist before you trust a traffic source report
A few checks catch most of the errors people make reading these reports for the first time. Confirm the date range matches the campaign you're actually trying to measure. A source breakdown for "last 30 days" will dilute a single week's push into noise. Check whether the report is showing sessions or users too, since a source with a high repeat-visit rate looks bigger by session count than it does by user count. And look at the medium column before the channel column: it's the layer most likely to hide a tagging mistake behind a tidy label.