| Takeaway | Detail |
|---|---|
| The California CPRA clock is 45 days per request, not one shared-terms deadline. | Thesis: the 45-day statutory deadline applies per request; one shared-terms route can centralize intake but cannot shorten it. |
| Use one shared intake ledger with a 45-day countdown for every California privacy request. | Reader rule: each request gets its own countdown in the ledger; do not run the countdown from the shared terms page. |
| Treat the shared terms page as disclosure only, never as the clock. | Reader rule: shared terms = disclosure layer only; the 45-day countdown lives on each request in the ledger. |
| Centralize the shared-terms route; do not let it reset or pause the 45-day clock. | Thesis: a single shared-terms route can centralize but cannot shorten the per-request CPRA 45-day deadline. |
This guide maps California CPRA privacy requests across editorial sites and paid products that share one terms page.
It specifies one intake ledger with a 45-day countdown per request and separates disclosure from the statutory clock.
How the 45-day clock actually runs
For a portfolio using a shared terms route, the CPRA clock is triggered by the consumer's request, not by the shared terms page. This means the operative moment is the intake timestamp recorded at the moment the consumer submits their request, not the publish date of the terms page. For every subscription product under that route, that timestamp must be the anchor, because the deadline runs from receipt, not from when notice was posted. Without that anchor, the timer has no verifiable start point.
One shared terms route can serve as a single disclosure surface across editorial sites and paid products, but that centralization only applies to notice. The shared intake ledger is the place where each request must be logged the moment it comes in, and from that moment, each request carries its own countdown. A request tied to one subscription product does not borrow the countdown from another, even if both fall under the exact same set of terms. The route can unify where people are directed, but it cannot unify when the timer begins.
This distinction holds for the full chain: the consumer initiates the request, the shared intake ledger must capture the exact receipt time, the terms page must point to the correct intake path, and the subscription product must be able to act on that specific request within its own countdown. If any part of that chain treats the terms page as the start, the ledger loses the trigger it needs to track. The responsibility is not to update the terms page faster, but to record the request faster.
A simple check for any team running this setup is to ask which date would be written down if a request came in well after the terms page was last updated. The answer must be the request receipt time. If the answer would be the terms page date, the process is treating the disclosure layer as the clock. That is the exact point of failure to correct, because the trigger is not the act of posting notice, but the act of receiving the request.
By locking the trigger to the consumer's request and enforcing a per-request countdown in the shared intake ledger, the portfolio can keep one route without diluting the deadline for any single request. The terms page can remain the disclosure layer, but the timer must remain tied to intake alone. That is the only way to keep one route and still respect a per-request deadline.
Evidence: what the sources actually show
For intake volume, the first check is recall: C+R Research, as reported by FOX 5 Atlanta, found that consumers spend about 2.5 times more on subscriptions than they estimate. That ratio is not about how much they care, but about how much they forget. For a portfolio where one set of terms covers multiple editorial sites and paid products, a California privacy request can come from a subscription the consumer no longer recalls by name. Because of that undercount, the intake path must be able to take the request without forcing the consumer to list every product they hold before it can be accepted.
Scale is the second check: according to Grokipedia's list of sovereign states by number of broadband Internet subscriptions, global fixed broadband subscriptions exceeded 1.3 billion in 2023, with the United States second at 131 million. These are fixed broadband subscriptions, not mobile broadband. The relevance is not per capita, but that subscription-based consumer relationships are the norm, not the exception. With that many fixed connections in one market alone, the class of recurring access is large enough that a shared disclosure layer will be seen by people who are likely holding more than they can name.
Put together, the 2.5x spend gap and the 1.3 billion global / 131 million United States fixed broadband figures point to the same operational pressure: matching. If consumers undercount by a factor of 2.5 and the base of fixed broadband subscriptions is measured in the hundreds of millions in the United States, the work is not getting the consumer to rebuild a full list of every subscription, but being able to route one request to every entity covered by the shared terms from minimal identifiers. A concrete check for any intake is to test that routing against an unremembered subscription, not a fully itemized one.
These are the only new figures introduced here: the 2.5x from C+R Research via FOX 5 Atlanta, and the 1.3 billion / 131 million from Grokipedia. They do not establish response obligations or costs, but they do establish why intake must be built for unremembered subscriptions at scale.
Options compared: one route vs per-product
For a portfolio of editorial sites and paid products sharing one set of terms, the comparison comes down to traceability, not presentation. Option A is a single shared-terms route paired with one shared intake ledger: one disclosure surface, one countdown per request, and one audit trail. By funneling every request to the same intake point, the portfolio only has to prove one timestamp per request, with no need to reconcile separate logs. This is the winner, because centralizing the path does not change the deadline, but it does make it enforceable across the entire portfolio.
Option B is per-product privacy routes, where each product runs its own intake, its own countdown, and its own disclosure. While this may appear to give each product full control, it multiplies the places a deadline can be missed. A request could go to a product form that is checked on a different schedule, or to one that has no portfolio oversight at all. Without a forced handoff between them, there is no way to know the full count of open requests at any time, and each new product added to the portfolio adds another intake path to monitor.
Option C is a shared terms page only, with no shared ledger. On the surface, this looks like consolidation, since the disclosure is in one place for all products. However, the intake itself remains scattered across product inboxes, contact forms, or support channels. With no single system of record, there is nothing to prevent requests from going unlogged entirely. Centralizing the text without centralizing the intake is not a middle ground, but the exact failure mode that leaves tracking up to chance.
Between these three, the choice is not about convenience for the visitor, but about accountability for the operator. A single shared-terms route with one shared intake ledger collapses every request into one trackable line of work. Per-product routes spread that work, and a shared page alone leaves it untracked. For a portfolio, only the first option creates one place to act, one place to verify, and one place to answer for every request that comes in.
Costs and numbers that matter
Two numbers anchor this section, and only two: the 45-day CPRA response window per request and the $15-per-year priority-shipping upgrade that TFH Magazine offers as a subscription-side fee. The 45-day figure is a statutory deadline, not a vendor benchmark, so treat it as a check to perform against the statute itself or the California Privacy Protection Agency's published materials before wiring it into a countdown. The ledger counts down 45 days for every open request; the shared terms page cannot shorten that countdown, pause it, or replace it with a portfolio-wide date. The $15-per-year TFH fee is the disclosure test: any subscription-side charge like it must appear in the same shared terms route that covers the portfolio, not be invented separately inside one product’s checkout.
The subscription-spend gap already documented in the evidence is why a consumer’s request may name a product the operator has forgotten the consumer holds. Operationally, that means the intake ledger needs a product-lookup step that searches every product line in the portfolio, not just the product named in the request. A request that says “cancel my subscription” without naming the product should still open a ledger row and start the 45-day countdown. The shared terms page can help the consumer identify products, but it cannot serve as the lookup mechanism itself.
The $15-per-year TFH priority-shipping upgrade is the fee-disclosure check. Audit every product’s checkout and renewal flow for charges that exist outside the shared terms route; if a fee appears in one product’s flow but not in the shared terms, either add it to the shared terms or remove it from the product flow. Do not let a product-specific fee live only in that product’s checkout, because the shared terms route is the disclosure layer the portfolio has chosen. The $15-per-year example shows the scale: small recurring fees are exactly the ones that get invented per product and missed in the shared terms.
Use the table below as the ledger’s number map: two hard numbers, two roles, two checks.
What to do next
| Step | Action | Why it matters |
|---|---|---|
| 1 | Create one shared intake ledger as the single route for every California privacy request that arrives through your subscription business, no matter which channel it comes in from. | Centralizing intake into one ledger is what a shared-terms route can legitimately do — it consolidates, it does not change deadlines. |
| 2 | Stamp each request with its own countdown at the moment it enters the ledger, set to the statutory period the CPRA gives you, and track it per row. | The deadline applies per request; each row needs its own clock, or you lose track of which requests are approaching their statutory limit. |
| 3 | Audit your shared terms page and strip any language implying it starts, resets, or pauses the countdown — relabel it as your disclosure layer only. | The shared terms page is where you disclose; it is never the clock. Any contrary wording invites noncompliance with the per-request deadline. |
| 4 | Check that routing a request through the shared-terms route never delays the countdown — intake centralization must not add days before the per-request timer begins. | A single route can centralize but cannot shorten the statutory deadline; any intake bottleneck effectively shortens your response window. |
| 5 | Review overdue and near-due rows in the ledger weekly, prioritizing any California request whose countdown is closest to expiry. | Per-request clocks mean one missed row is one violation, even if every other request was handled on time. |
| 6 | If you cannot complete a request within the statutory window, document the extension in that request's ledger row under the CPRA's extension rules before the base period lapses. | The extension belongs to the individual request, not to the shared-terms route — recording it per row keeps the disclosure layer and the clock cleanly separated. |
Frequently Asked Questions
Does publishing a shared terms page start the CPRA deadline for subscribers?
No, the clock is triggered by the consumer's request and the intake timestamp recorded when they submit it, not the publish date of the terms page.
If we route all subscription products through one shared terms page, can that shorten the statutory deadline?
No, a single shared-terms route can centralize intake but cannot shorten the per-request statutory deadline.
Should I run the countdown from the shared terms page for every California privacy request?
No, each request gets its own countdown in the intake ledger, and the shared terms page must be treated as the disclosure layer only, never as the clock.
Can the shared-terms route reset or pause the statutory clock once a request comes in?
No, you should centralize the shared-terms route but never let it reset or pause the per-request countdown.
How should we track California privacy requests across editorial sites and paid products that share one terms page?
Use one intake ledger with a separate countdown for every California privacy request, separating disclosure from the statutory clock.
Does the CPRA deadline work differently for individual subscription products under a shared terms route?
No, for every subscription product under that route the statutory clock is per request, with the operative moment being the intake timestamp at submission.
Quick answers
| What is the California CPRA clock per request? | The California CPRA clock is 45 days per request, not one shared-terms deadline. |
| What can a single shared-terms route do to the per-request CPRA 45-day deadline? | A single shared-terms route can centralize but cannot shorten the per-request CPRA 45-day deadline. |
| What triggers the CPRA clock for a portfolio using a shared terms route? | The CPRA clock is triggered by the consumer's request, not by the shared terms page. |
| What is the operative moment for the CPRA clock? | The operative moment is the intake timestamp recorded at the moment the consumer submits their request, not the publish date of the terms page. |
| How should the shared terms page be treated? | Treat the shared terms page as disclosure only, never as the clock. |