Pocket referrer traffic
Pocket is a save-for-later reading service where people queue articles to read on their own schedule. Web reads can appear as getpocket.com referrals, but the apps frequently send no referrer and reads are time-shifted, so UTM tags are the reliable way to attribute Pocket-driven visits.
What this means
Pocket is a save-for-later service: people save your article and read it later, often on a phone or tablet. When the saved page is opened on the web, traffic can reach your site as a referral from getpocket.com.
The defining trait is time-shifting. Unlike a social click that follows a post immediately, a Pocket read can happen hours or days after the save, so the visit may not line up with the moment your content was published or shared.
Why the referrer can be missing
Pocket's mobile and reader apps commonly open articles without forwarding a Referer header, sending those reads to direct or unknown traffic. Referrer-policy downgrades and in-app readers reduce detail further.
Tag links you control or submit with utm_source=pocket and utm_medium=referral. The query string survives the reader and persists when the saved URL is reopened, so read-it-later clicks stay attributable to Pocket even when the Referer header is absent and the read is delayed.
- Host you may see: getpocket.com
- Recommended tags: utm_source=pocket, utm_medium=referral
- Reads are time-shifted and app reads arrive direct/unknown — UTM recovers them
How it appears in analytics and logs
A referrer on getpocket.com means a visitor opened your article from their Pocket queue on the web. App reads often arrive with no referrer, and because reads are time-shifted, Pocket traffic may appear days after the save.
Diagnostic use case
Recover delayed read-it-later clicks that would otherwise be filed as direct, and understand that Pocket traffic can arrive long after the original share.
What WebmasterID can help detect
WebmasterID groups Pocket referrals as a read-it-later channel and reconciles them with your UTM tags, so delayed reading clicks stay separate from genuine direct traffic.
Common mistakes
- Expecting Pocket traffic to align with publish time — reads are time-shifted.
- Assuming all Pocket reads show getpocket.com — app reads arrive as direct.
- Leaving controllable Pocket-saved links untagged, losing clicks to direct traffic.
Privacy and accuracy notes
Attribution uses only the Referer header and any UTM parameters. No Pocket account or reader is identified. WebmasterID records the channel, not the person.
Related pages
- Inoreader referrer traffic
Inoreader is an RSS and feed-reader service where people subscribe to your feed and read articles in the reader. Web clicks can appear as inoreader.com referrals, but app and mobile reads often send no referrer, so UTM tags are the reliable way to attribute Inoreader-driven visits.
- Feedly referrer traffic
Feedly is an RSS feed reader where subscribers follow your content and click through to read in full. Web clicks can appear as feedly.com referrals, but mobile-app reads frequently send no referrer, so UTM tags on your feed links are the reliable way to attribute Feedly traffic.
- Referrer grouping into channels
Analytics platforms do not report every raw referrer separately — they map hosts into channel groups such as organic search, paid, social, referral, email, and direct. Understanding the default rules explains why a click ends up in one bucket versus another, and why a custom source can be misfiled until you adjust the grouping.
- Campaign links
Tag links so delayed read-it-later clicks are attributable despite a missing referrer.
Sources and verification notes
- Pocket — getpocket.comPlatform description; in-app referrer behaviour is a general reader-app pattern.
- MDN — Referer header
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.