Subdomain subscriptions
Each Hood container (one property / one push app) has a setting called Enable subdomain subscription. It controls how web push behaves when your site spans several subdomains, such as www.example.com, sport.example.com, and news.example.com.
Default: off. One site, one subscription. Most publishers should leave it that way.
When to turn this on
Almost never. Turn it on only when related hosts are separate publishers — different products with their own container each (for example, a news brand and a jobs portal running on subdomains of the same parent domain). If all your subdomains belong to one brand with one push audience, leave it off.
What it does
Web push subscriptions are always tied to a single website origin — a browser cannot share one push subscription between sport.example.com and news.example.com. What Hood can do is coordinate related hosts of the same site:
| Off (default) | On | |
|---|---|---|
| Model | One audience for the whole site | Each subdomain is a separate publisher |
| After a visitor subscribes on one subdomain | Related subdomains of the same domain do not show the push prompt again and do not create another subscription | Each host can prompt and collect its own subscription |
| Use when | One brand, several subdomains | Different products / different containers per host |
Expected behavior — Off
- A visitor allows push on subdomain A.
- The same visitor opens subdomain B (same parent domain, container with the setting off).
- They are not asked again. They stay subscribed to the original site.
Expected behavior — On
- A visitor allows push on host A (container A).
- The same visitor opens host B (container B, setting on).
- They can be asked again and can subscribe to B. The subscription on A is unchanged.
What it does not do
- It does not control where the SDK runs. That is the Domains allowlist — see Domains vs. this setting below.
- It does not share a visitor or profile ID across subdomains. Visitor IDs are stored per origin; two subdomains never share one user ID in the browser.
- It does not create multiple subscriptions on one profile. Hood stores one subscription per profile. Two origins means two subscriptions, which means two profiles.
- Consent is not a subdomain switch. Leave Consent on. Turning Consent off does not isolate subdomains and drops your prompt/allow statistics.
Which setup do I need?
| Your situation | Enable subdomain subscription | Domains list (typical) |
|---|---|---|
| One brand, several subdomains (www, sport, news), one push audience | Off | example.com and *.example.com |
| Only one host, no other subdomains using this SDK | Off (default is fine) | that host, or *.example.com if you want sibling hosts later |
| Two or more separate publishers on related hosts, one container per host | On, on every container involved | each container lists its own exact hostname |
Domains vs. this setting
The Domains list decides where the tag runs; subdomain subscription decides how many push audiences you get. Don’t mix the two.
The SDK only runs if the page hostname matches an entry in Domains:
| Entry | Matches | Does not match |
|---|---|---|
example.com | that host only | sport.example.com |
*.example.com | sport.example.com, a.b.example.com | apex example.com |
| both entries | apex and all subdomains | other sites |
An empty or missing list means no restriction — the SDK runs on any host.
Note for existing customers
Older dashboard versions used an inverted “suppress prompt” checkbox that stored the opposite value. After the rename:
- Off saves
false(or omits the key). - Containers created under the old UI may already have the setting on without you intending separate publishers. Open the container and confirm the checkbox matches your intent.
Do not disable Consent to isolate subdomains. That was a workaround for the old SDK; on the latest SDK it does not isolate push, and it hides prompt/allow statistics.
FAQ
I only have one subdomain. What should I pick? Leave it off. The default already gives you one subscription for your site.
Can one visitor profile hold subscriptions from several subdomains? No. Each origin creates its own subscription on its own profile.
Does *.example.com in Domains cover example.com too?
No. The wildcard covers subdomains only; add the apex as a separate entry.
For developers
In auto-conf and the init API, this setting is the boolean key push_enable_subdomain_subscription (checkbox on = true, off = false or omitted; there is no inversion). With the setting off, a non-identifying cookie _ocpsh=1 is set on the registrable domain after subscribe so sibling hosts skip the pre-prompt — it is not a tracking cookie. With the setting on, that cookie is not used; a per-origin flag in first-party storage tracks subscription state. The browser keeps one push subscription per origin and service-worker scope; a different VAPID key on the same origin replaces the previous endpoint rather than stacking. Full details: Push notifications (Web SDK).