Google Discover, decoded

If Discover is a giant newspaper with many distribution kiosks, Content is the main one. About one in three articles in France enters Discover through this pipeline. It's where most editorial articles land first before potentially being amplified by other pipelines.

Moonstone is the pipeline with the largest reach in France. Once an article is picked here, it's broadcast to a huge audience. The catch: it strongly favours sites with a long history of high engagement, which is why a single regional player (Ouest-France) captures most of its volume.

A pipeline focused on product reviews, deals, gift guides, and shopping inspiration. Articles here have unusually long shelf life — 3-4 days versus a few hours for breaking news — because shopping intent is sticky. Great pipeline for affiliate sites and e-commerce magazines.

Feedads is the ads/sponsored content pipeline. It's almost completely isolated from the editorial pipelines: 99.8% of the URLs that ride Feedads never appear elsewhere in Discover. Editorial publishers rarely interact with it directly.

Aura's job is to inject diversity into the feed — bringing in long-form, well-researched articles that complement the breaking-news firehose. It rewards depth, narrative, and research over breaking-news velocity.

Mustntmiss is Discover's 'don't miss this' pipeline — Google flags certain articles as essential reading on a topic and doubles their priority. Once an article enters Mustntmiss, its visibility roughly doubles compared to a standard Content placement.

The breaking-news pipeline. The median article on this pipeline is 2.2 hours old — by Discover standards, that's basically real-time. Almost half of its content never appears anywhere else, making it a pure breaking-news channel.

Creatorcontent surfaces content tied to social activity — primarily X/Twitter posts in France (75% of its sources). It exploded ×33 in 3 months, reflecting Google's bet on creator-driven content. A site with no active X presence renounces an increasingly large share of Discover traffic.

Astria has an unusual property: it doesn't surface articles immediately — the median delay between publication and surfacing is 1.5 days. This makes it a 'second-wind' pipeline. Articles that didn't catch fire on day 1 can find a second life via Astria on day 2-3.

Surfaces stories that are geographically relevant to where the user is right now. A traffic accident in Toulouse only surfaces to users in or near Toulouse via this pipeline.

The dedicated regional-press pipeline. Two-thirds of its content is unique to it. National media practically never appear here — it's the playground of regional newspapers (Ouest-France, La Voix du Nord, Sud Ouest, etc.).

Behind the 'Top stories' carousels and Showcase widgets, this pipeline groups together multiple articles that cover the same event. Being included in such a group massively amplifies traffic.

When a user has already clicked one of your articles, Relatedcontentruby kicks in to suggest more of yours on similar topics. It's how a single hit can multiply your visits — a strong reason to publish coherent topical clusters.

The deeper a user scrolls in their Discover feed, the more this pipeline kicks in to fill the slate. Its volume has grown ×7 in 3 months, signaling that Google is increasingly relying on engaged users to consume more content per session.

The pipeline dedicated to video content (mostly YouTube broadcasts). Massive in the English market (13% reach) but barely exists in France (~36 hits in 3 months = noise level). For French publishers, video is not a priority Discover lever.

A two-stage detection system. Deeptrendsfable spots that something is starting to trend (sudden spike in queries, mentions, social shares). Deeptrends then takes over to keep amplifying it as long as the trend persists.

A specialised architecture where Google's server actively pushes notifications without waiting for the user to open the Discover feed. Limited to live-sports scores and finance market recaps for now.

The very first step. Google's crawler fetches the URL, reads the HTML and extracts every entity it recognises (people, places, brands, events). Each entity gets matched to a Knowledge Graph identifier (MID). Sites in Google News are crawled within minutes; the rest can wait 1-24 hours.

The Google App SDK contains a class explicitly named SchemaOrg{parsedMetatags, jsonLdScripts}. The decompilation revealed: when JSON-LD is present, it OVERRIDES whatever Open Graph or Twitter Card claim. Most SEO guides got this wrong for years — they advised optimising OG, but Discover prioritises JSON-LD.

Google App's code confirms 13 cluster types. Your article isn't tagged 'tech news' — it's tagged with a combination of internal cluster IDs (moonstone-cluster, neoncluster, content-cluster, etc.). An article can ride multiple clusters at once. This is how the same article can be amplified by multiple pipelines.

The brutal step. Two filters run: 'collection' filters at the domain level (entire site blacklisted? out), 'entity' filters at the URL level (this specific article violates a policy? out). This step runs BEFORE ranking, so a blacklisted site never even gets evaluated for relevance — it's already excluded.

The personalisation layer. NAIADES looks at: who is this user (their embeddings — Nephesh, Picasso, VanGogh), what topics they've engaged with (MID-based), what they've searched recently (Query-based), what's their current session about. Then matches articles to users with high alignment.

The actual scoring. Happens entirely on Google's servers and remains the most opaque step. What we know: it's strongly informed by behavioural signals from NavBoost (clicks, dwell time, pogo-sticking) plus quality signals from steps 1-2 (structured data quality, entity coherence) and personalisation match from step 5.

Critical revelation from the SDK decompilation: when you scroll Discover, you're not browsing a pre-computed list of cards. The feed is a gRPC stream, continuously assembled as you scroll. Cards can be inserted, demoted or removed in real time based on what you're doing.

The closing loop. Every action you take (click, swipe-away, 'don't show me this again', share, long dwell) feeds back into the system. Dismissed content gets permanently 'tombstoned' for that user. NavBoost incorporates the new behavioural data and adjusts site-level scores. The loop runs in real time — within seconds.

If you remember only one technical name from this glossary, it should be this one. NavBoost watches every click, dwell time, scroll depth, pogo-stick and share — primarily through Chrome — and continuously rescores sites and articles. On Discover (unlike classic SEO), NavBoost effects are instant: a bad article gets cut within hours.

NAIADES is the layer that decides 'should THIS article be shown to THIS specific user'. NavBoost says how 'good' an article is in general; NAIADES says whether it's a match for you specifically. It uses 7 different sub-types — MID-based (entities you care about), Query-based (recent searches), WPAS (publisher status), RECALL_BOOST, AIM Thread, and others.

Think of the Knowledge Graph as Google's giant index card system: every notable person, place, brand, event has its own card with a unique ID (MID). Discover uses this index to understand what your article is REALLY about — not just keywords. The more your article mentions properly-recognised entities, the better Discover can match it to the right audience.

Every entity in the Knowledge Graph has a MID — its 'social security number' inside Google's systems. Apple Inc. = /m/0k8z. Tim Cook = /m/0gxhdx. When your article correctly resolves to entities with stable MIDs, Discover indexes those MIDs alongside your URL and routes traffic accordingly.

When your article says 'Apple', Google has to decide: which Apple? The fruit, the company, the record label, a specific person? Entity linking is the algorithm that resolves this ambiguity using context, then attaches the right MID. Inconsistent naming hurts entity linking.

SAFT is the Google internal system that runs entity extraction at scale across the whole web. It handles coreference resolution ('he' → 'Tim Cook'), relation extraction ('founded' between 'Steve Jobs' and 'Apple'), and feeds all of this into the Knowledge Graph.

A 'twiddler' is a small re-ranking module that takes the already-scored result list and applies last-minute nudges (boost certain freshness, demote duplicates, enforce diversity quotas). Discover uses several twiddlers chained together. Their effect is small per twiddler but cumulative.

If Google judges that your headline doesn't match what the article actually delivers, Goldmine may rewrite it on-the-fly for display in search/Discover cards — using your H1, og:title, JSON-LD headline, or even synthesised text. A divergence between H1 and Title increases the chance Goldmine rewrites you (often badly).

Nephesh is the deepest, slowest-moving 'who you are' representation. It's built over months from your behaviour across every Google product and rarely shifts dramatically. When you log into a brand new device, Nephesh already 'knows' you — that's why your Discover feed is personalised on day one.

Picasso runs in batch jobs (every few hours / days) and synthesises two complementary signals: STAT (Short-Term Affinity Track, last few weeks) and LTAT (Long-Term Affinity Track, last few months). It's faster-moving than Nephesh but still much slower than your current session.

VanGogh runs ON YOUR PHONE in real time. As you open, scroll, click, swipe in the current session, VanGogh updates within seconds. This is what makes Discover feel responsive: dismiss two clickbait articles → the next slate already shifts away from clickbait.

Just as Nephesh embeds a user, Site2vec embeds a site. It's the mathematical 'fingerprint' of what your site is about as a whole. Discover compares Site2vec(your site) against user embeddings to decide site-level affinity, and against other sites' Site2vec to spot competitors and overlaps.

Computed from Site2vec, this score answers: 'how tightly clustered is this site's content around a coherent theme?' A site with a clear focus (e.g. cycling magazine) scores high. A generalist news site scores lower. High SiteFocusScore = Discover trusts the site as an authority on its niche.

The flip side of SiteFocusScore. SiteRadius measures HOW FAR your articles drift from your site's centroid. A small radius means tight thematic discipline; a large radius means scattered content. Discover penalises high-radius sites because they look opportunistic.

If you've recently read articles tagged with /m/0k8z (Apple Inc.), MID-based scoring lifts other articles tagged with the same MID for you. This is why your Discover feed gets 'sticky' on entities you care about — once Apple is in your active MID set, Apple-related cards keep surfacing.

Your Discover feed reacts to what you've Googled in Search. Searched 'best espresso machines under 500€' yesterday? Espresso content surfaces in Discover today. The window is short (last few days) but the effect is strong — 'follow-up surfacing' is one of Discover's most reliable mechanics.

If your site is registered (and approved) in Google Publisher Center, WPAS gives every one of your articles a small but persistent boost in distribution. Free signup, ~10 minutes setup, materially raises your distribution ceiling. Why most non-news publishers ignore it is genuinely puzzling.

At the moment Discover is assembling your slate, it pulls from a giant pool of candidate articles. RECALL_BOOST increases the chance that a specific article gets pulled into the candidate set in the first place. Earlier and broader exposure than what NavBoost alone would warrant.

AIM stands for Affinity-Interest Modelling. An AIM Thread is a topical 'thread' you've been pulling on — say, you've been following the World Cup across multiple sessions. NAIADES persists this thread across sessions and surfaces follow-up content even days later, before the topic naturally surfaces from your other signals.

The single most important early signal. Discover shows your card a small audience first; if CTR is high (~7-12% in France), the article is amplified. Below ~3%, distribution gets cut quickly. The headline-image combination drives 80% of CTR — get those right or nothing else matters.

If a user stays on your article for 90+ seconds, NavBoost reads that as 'the title delivered'. If they bounce in 8 seconds, it reads as 'oversold/clickbait'. Dwell time is harder to fake than CTR — even bot traffic struggles to mimic genuine reading patterns.

The user clicks your card, sees the page, immediately goes back to Discover. That's a pogo-stick. It's the worst kind of click — Google now KNOWS the title oversold and the user is annoyed. Even a single pogo-stick is bad; a high pogo-stick rate kills distribution within minutes.

Google internally categorises clicks as 'long' (the user got their answer) or 'short' (the user came back to look for something better). Discover overlays this with dwell time and pogo-stick to score satisfaction. Sites with high long-click ratios are systematically promoted.

Discover instruments this event sequence very tightly. The latency between 'arrive on article' and 'press back' is one of the cleanest quality proxies available — much harder to fake than CTR or pageviews.

If users consistently bail at the 30% mark, that's a sign the lede is wasting time before getting to the value. If they scroll to 90%+, you've nailed the structure. Long-form articles with low scroll depth are a Discover red flag.

When a user clicks 'Don't show me this again' or 'Not interested in this site', Discover writes a permanent marker against that combination. The content (or the entire site) will never appear in that user's feed again. Per-user, but irreversible at the user level.

If you publish an article, get distribution, then update or remove the article in a way that breaks the original promise (e.g., behind a paywall after the fact, redirect to ad-heavy content), Discover counts that as a 'rug pull'. High counts correlate with editorial unreliability and distribution gets clipped.

Wave 1 (~1000-5000 impressions): the test phase, narrow audience, used to estimate CTR and dwell. Wave 2 (~50k-500k): broader test if signals are good. Wave 3 (1M+): mass amplification — only ~5% of articles ever reach this. This staged exposure is why hours 0-2 after publication are critical.

The three vital signs Google checks on every page visit. Failing any of them is a hard ceiling on Discover distribution. The standard is 'pass-rate ≥ 75% of visits' — meaning at least 3 out of 4 of your visitors must hit the targets.

LCP measures when the main image or the largest text block becomes visible. Below 2.5s = user perceives the page as 'fast'. Between 2.5-4s = mediocre. Above 4s = bad — users start bouncing. The hero image is usually the LCP element on a Discover article.

Sum of all unexpected layout shifts. Aim for < 0.1. Common offenders: ads loading after the main content (everything jumps down), images without explicit width/height, fonts swapping. Mobile is especially punishing — a single ad insertion can blow your CLS.

Replaced FID in 2024. Measures every interaction (taps, key presses) across the page lifetime, then takes the slowest one. Below 200ms = responsive. Above 500ms = janky, JavaScript is blocking the main thread. Heavy ad scripts are the #1 offender.

The time between the user's request and the very first byte of HTML arriving. Below 500ms = good. Above 800ms = your server is dragging the whole experience down. Cheap shared hosting often has TTFB > 1s — that alone makes Discover-grade performance impossible.

A composite score combining LCP, CLS, INP, TBT, etc. Discover is mobile-first, so the desktop score doesn't matter — only the mobile (slow 4G, mid-range device) score does. Below 70 = your distribution is materially capped, even if individual CWV pass.

Google's quality raters (humans) evaluate content along these four axes. Experience: did the author actually live this? Expertise: are they a recognised expert? Authoritativeness: does the site have a track record on the topic? Trustworthiness: is it accurate and transparent? Strong E-E-A-T = sustained Discover distribution. Weak E-E-A-T = capped at Wave 1.

If your content can affect someone's health, money, safety or major life decisions, Google applies a much higher quality bar. YMYL articles need verified authors (Schema Person + bio + credentials), reputable sources, and clear disclaimers. Lazy YMYL content gets crushed by both quality raters and HCS.

HCS rolled into the core algorithm in 2024. It evaluates whether content brings real, original value or just regurgitates what's everywhere else. SITE-LEVEL signal: a few thin pages can drag down your whole site's distribution, even on your good articles. Recovery requires removing or rewriting the thin content, not just the new pages.

Active since May 2024, aggressively enforced. The classic case: a top news site rents out a /coupons subdirectory to an affiliate company. Google now penalises this — the parasitic content gets blocked AND the host site gets a reputation hit.

The classic 'show clean text to Google, redirect humans to spam' trick. Modern cloaking is more subtle — JavaScript that swaps content based on user-agent fingerprinting. Discover detects it via Chrome telemetry (the rendered DOM in real users' Chrome doesn't match what Googlebot saw). Triggers manual action and full Discover suspension.

A few thousand contractors worldwide. They don't directly affect rankings — their evaluations train Google's ML models. The rater handbook (170+ pages, public) is the single best source on what Google considers 'quality'. Reading it is unfair edge.

When one of your articles becomes a runaway hit on Discover, your entire site benefits temporarily — other articles see higher CTR, faster pickup, broader distribution. The halo lasts 7-21 days. This is why publishers chase 'one breakout per week' more than 'consistent baseline'.

A small JSON block in your <head> that tells Google exactly what your page is about, in machine-readable form. The Google App SDK was decompiled and the parser explicitly prioritises JSON-LD over Open Graph and Twitter Card. If your JSON-LD says one thing and your og:title says another, Discover trusts the JSON-LD.

A shared vocabulary maintained by Google, Microsoft, Yahoo and Yandex. Defines hundreds of types (Article, Person, Recipe, Event, Product, etc.) and properties (name, author, datePublished, etc.). When you use it correctly, all major search engines understand your content the same way.

A specialised sub-type of Article for time-sensitive news content. NewsArticle accepts dateline, printSection and other journalism-specific properties. The Google App parser handles NewsArticle differently from generic Article — preferring it for distribution. Misusing NewsArticle for evergreen guides can trigger demotions, though.

Inside your NewsArticle JSON-LD, the author should be a full Person object: name, url (to author page), sameAs (Wikipedia, X, LinkedIn), jobTitle, knowsAbout. Missing or shallow author data is the #1 reason YMYL articles fail to gain traction in Discover.

Each NewsArticle's JSON-LD should reference your site as a publisher Organization: name, url, logo (with explicit width/height), sameAs (social profiles), foundingDate. This is what binds your articles to a recognised entity in the Knowledge Graph and unlocks WPAS-style boosts.

Tells Google: this article lives at /tech/iphone/iphone-16-review. Powers the breadcrumb that sometimes replaces the URL line in cards. Helps Google understand your site's category structure — feeding into SiteFocusScore and SiteRadius.

When you reference an image inside Article markup, wrap it as ImageObject with explicit dimensions. This lets Google pick the right hero crop for the Discover card and accelerates LCP measurement. Naked image URLs with no metadata leave Google guessing.

Wikidata is the structured-data backbone Google uses to disambiguate entities. Adding sameAs links from your Schema Person/Organization to Wikidata Q-IDs concretely helps Google resolve your entities and assign you a stable MID. Free, public-domain, takes 15 minutes per entity.

Without this directive, your hero image cannot be used as a Discover card thumbnail at full size — Discover falls back to a tiny 100x100 crop or no image at all. The single most-forgotten tag on Discover-aspiring sites. Add it in your <meta name="robots"> alongside index, follow.

The single highest-leverage visual on the page. Discover's 1200×800 minimum is non-negotiable — below that, the image gets pillar-boxed and CTR drops by 30-50%. The hero must be original, sharp, and emotionally engaging. Stock photos underperform original photography by 2-3× on CTR.

The two ratios Discover uses. 16:9 for most cards, 4:3 for compact slots. If your hero image isn't already in one of these ratios, Google will crop it — often badly (cropping out the subject). Author your hero in 16:9 (1344×756 or larger) and you control what's visible.

Google can spot a stock photo or a 100×-reposted image instantly via reverse-image hash. Original visuals (your own photography, custom illustrations, photographed product shots) outperform stock by 2-3× on CTR — often by an order of magnitude on competitive topics.

The C2PA standard adds a cryptographic 'origin' tag to images, indicating whether they came from a camera or an AI generator. IPTC fields can also carry this. Discover doesn't ban AI images, but undisclosed AI imagery presented as photographic evidence on YMYL topics gets flagged and demoted.

When a page has multiple candidate images, alt text helps Discover pick the most relevant one. Keep it descriptive (what's in the image) and topic-relevant (uses your target keyword naturally). Stuffing keywords backfires.

There must be exactly one H1 per article, and it should match the title users see in the Discover card. Mismatch between H1 and Title is one of the most common Goldmine triggers — Google rewrites your headline (badly) when it can't trust it.

The single highest-leverage piece of copy on the entire page. Discover often shows it verbatim, sometimes truncated to 70 characters. Sweet spot: 50-65 characters. The first 50 chars must contain the curiosity hook because that's what survives truncation on small-screen mobile.

Discover only renders the meta description on a fraction of cards (mostly larger formats). It's not the primary lever, but it remains a tie-breaker for click-through prediction in some pipelines. Don't ignore it; don't obsess over it either.

Originally built by Facebook for social sharing. Discover's parser uses og:* as a SECONDARY source, only when JSON-LD is missing or incomplete. og:image is consulted for the card image when no Schema ImageObject is present. Keep og:* aligned with JSON-LD to avoid Goldmine rewriting.

Used by X/Twitter (and now creatorcontent pipeline indirectly). For Discover ranking purposes, it's the LAST fallback after JSON-LD and Open Graph. Still worth setting correctly because creatorcontent specifically reads it when articles are shared on X.

Declared via <link rel='canonical'>. When the same content lives at multiple URLs (mobile/desktop, syndication, paginated), canonical tells Discover which one is THE one. Inconsistent or self-canonicalising-then-not is a known way to fragment your own NavBoost score.

Free signup, ~10 minutes setup. Approved Publisher Center sites get: (1) the WPAS personalisation boost, (2) sub-minute crawl latency vs 1-24h for unregistered sites, (3) eligibility for Google News inclusion. The single highest ROI action for any Discover-aspiring site.

A REST API where you POST a URL and Google crawls it within minutes. Officially limited to JobPosting and BroadcastEvent schema types — but news publishers commonly use it as an unofficial fast-lane for breaking content. Use sparingly: abuse triggers throttling.

A specialised sitemap that signals 'these URLs are time-sensitive news' to Googlebot. URLs in news.xml get crawled within minutes (vs hours for regular sitemap.xml). Maximum 1000 URLs, only articles less than 48h old. Pings Search Console on every update.

Confusingly often presented as a 'faster indexing' silver bullet — but Google has explicitly stated it ignores IndexNow signals. Useful for Bing visibility, neutral for Discover. Many CDNs (Cloudflare) enable it by default; that's fine, just don't expect Discover effects.

The combo Discover needs: index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1. Anything stricter (e.g. noindex, max-snippet:50) silently caps your distribution. Single most common cause of 'why doesn't my site appear in Discover at all?'.

Limited resource. If your site has 100k thin pages, Googlebot wastes its budget there instead of crawling your fresh articles. Trim the deadwood (noindex tag pages, paginated archives, etc.) to focus the budget where it matters.

Free, takes 5 minutes to verify. The Discover-specific tab only appears once your site has accumulated > 100 Discover impressions in 16 months — its mere existence is a signal that you're eligible. Tracks Discover separately from Search.

Shows total Discover impressions, clicks, CTR, and per-article performance over the last 16 months. Doesn't expose pipelines or NAIADES sub-types — for that you need third-party tools like 1492.vision or DiscoReady.

A human at Google has reviewed your site and applied a penalty for a clear policy violation (spam, hidden text, hacked content, site reputation abuse). Listed in Search Console > Manual actions. Requires a reconsideration request to lift, often after concrete remediation.

The system itself decided to demote you, no human involvement, no notification. Detectable only by sudden, sustained drops in Discover impressions while Search remains stable. Recovery means fixing the underlying signal — most often Helpful Content System triggers.

Google ships 3-6 named updates per year. Core updates re-tune ranking; Spam updates target policy violators. Discover sites can lose 70%+ of distribution in a single update — much more volatile than Search. Recovery rarely happens before the next update.

Controversial but documented hack: in the first hour after publication, drive 100-300 'real-looking' direct clicks (push notifications, social shares, internal site CTAs). NavBoost reads the elevated engagement on hour 1 and triggers Wave 2 amplification. Risk: Google's anti-fraud detects mechanical patterns. The cleaner the source (real users), the safer.

Build a push subscriber list (OneSignal, Outpush). Within 30 minutes of publishing, push the article to your warm audience. Their clicks count as 'direct' in NavBoost — same effect as the direct-clicks hack but fully legitimate. Sites with 100k+ push subs can self-trigger Wave 2 reliably.

Discover's algorithm makes a 'gut decision' in hour 0-2 based on Wave 1 signals. If CTR + dwell + scroll-depth all look great, Wave 2 fires within 90 minutes. If they're mediocre, the article gets quietly capped. Hour 2 onwards, the trajectory is mostly locked in.

Discover's user activity peaks differ by topic. Lifestyle / horoscope: 5h-7h French time. Tech / business: 8h-10h. Entertainment: 19h-22h. Publishing into the right window can change Wave 1 by 5-10× and trigger Wave 2 that wouldn't have fired otherwise. Underrated lever.

Material content updates (new sections, refreshed numbers, updated dates) on a previously-distributed article can trigger a new Discover cycle, with the benefit of the article's existing NavBoost history. Cosmetic-only updates (changing dateModified without real content change) are detected and demoted.

Named after a notable case study. When an author has a strong, well-built profile (Schema Person + bio + sameAs to X/Wikipedia + active publication history), every new article they sign benefits from the author's accumulated authority. Often a 1.5-3× lift on Wave 1 CTR.

Every site that's been recognised by Google as a publishing entity has a Google Web Profile at profile.google.com/cp/[id]. The presence of this URL is the cleanest proof that your domain is in Google's entity index. The DiscoReady Profiler tool surfaces it for any site in one second.

The platform you're reading this glossary on. Free tools (Profiler, Title Lab, Image Validator, Schema Auditor, 1-min Audit) plus the Premium Guide that this glossary is built from.

The dominant source feeding the creatorcontent pipeline in France. A site without an active X presence (a verified handle posting article URLs with hooks, accumulating engagement) renounces a growing share of Discover traffic.

Reference case study: high publication frequency, broad topic coverage, never a clear winner on any single pipeline. Volume strategy works but caps your per-article ceiling — opposite of Ouest-France's pipeline-domination model.

The reference success case in French Discover. Builds tight thematic verticals (regional news, sports, lifestyle), each strong enough to dominate its respective pipeline. Captures the largest share of Moonstone, Webkicklocalstories and Mustntmiss in France.

Once your Discover traffic is meaningful (~100k visits/month), graduating from AdSense to a specialised network like HBAgency typically yields 2-3× the per-thousand-impressions revenue. The single biggest monetisation lever for FR Discover sites.

A French SaaS for browser/web push notifications. Frequently used to drive the 100-300 first-hour clicks that trigger Wave 2 amplification. Cleaner than mechanical click-injection because the clicks come from real opted-in subscribers.

Third-party analytics tool built specifically for Discover. Reveals which of the 20+ pipelines each of your articles entered, what their pipeline-level performance looks like, and how that compares to competitors. Around €200-500/month — rentable above 100k Discover visits/month.