Proton VPN Pricing A/B Test: How One HTML Tag Correlates With a €12 Difference in What Customers Pay

A pricing page is one of the least interesting places to look at a website if all you care about is how the site works. It becomes considerably more interesting when the same product appears at two different prices, the difference survives repeated testing, and the page’s own HTML contains an identifier explicitly describing an A/B test.

That is what I found while examining Proton VPN’s pricing page on August 8, 2026.

The important thing is between what can be demonstrated from the evidence and what cannot. The evidence supports the conclusion that, during the observation window documented here, protonvpn.com/pricing assigned visitors to at least two variants and that the assigned variant corresponded consistently with two different introductory prices for VPN Plus. It does not, by itself, establish why Proton ran the experiment, whether the company intended to deceive anyone, whether personal information was used to determine the price, or whether only two variants existed globally.

Those matter, particularly because a competing VPN provider, Windscribe, publicly accused Proton of misleading customers about the reason for the price differences. That allegation is part of the story, but it is not the same thing as independently establishing the allegation. The technical evidence is much more concrete.

What happened

On August 8, Windscribe published a five-part thread claiming that Proton VPN was showing different VPN Plus prices to different visitors and that the behaviour represented price-sensitivity A/B testing rather than residual pricing from an expired sale. Windscribe pointed to an HTML meta tag on Proton’s pricing page:

<meta name="ab-test:VpnHpAndPricingVpnPlusSensibility300726" content="A">

or:

<meta name="ab-test:VpnHpAndPricingVpnPlusSensibility300726" content="B">

Windscribe’s thread also distinguished price-sensitivity testing from adaptive or dynamic pricing. A price-sensitivity experiment can randomly assign different prices to different users and measure conversion or revenue. Dynamic or adaptive pricing, by contrast, can use information about a customer or market conditions to determine the price offered to that particular customer.

Windscribe’s post was not the first public mention of the tag. A discussion on the Proton VPN subreddit had already reproduced the same identifier and included developer-tools screenshots showing the two values. Proton’s General Manager had also responded to earlier reports of inconsistent pricing, saying that there was no adaptive pricing, that a recent sale had ended, and that the lower prices being reported appeared to be an error that had not universally refreshed.

That chronology is important because it prevents a common mistake in reporting this story: presenting the discovery of the ab-test: tag as though it originated with this investigation. It did not.

What had not yet been demonstrated publicly was the precise relationship between the variant letter and the price shown to the customer.

That is the narrower question examined here.

A/B testing is not the same thing as dynamic pricing

The terminology deserves some care because the words are being used interchangeably in parts of the online discussion.

A/B testing is a standard technique in software development. A systematic literature review published in the Journal of Systems and Software describes it as comparing software variants in a live environment from the end user’s perspective. The published study analyzed 143 primary studies, while the earlier 2023 version of the research reported 141. The difference comes from the research versions, not from a contradiction about what A/B testing is.

A conventional experiment might look like this:

                    Incoming visitors
                           |
                    Experiment system
                           |
                +----------+----------+
                |                     |
             Variant A             Variant B
                |                     |
          $2.99/month             $3.49/month
                |                     |
             Purchase             Purchase
                |                     |
                +----------+----------+
                           |
                     Measure results

The experiment can then compare metrics such as conversion rate, revenue, abandonment, clicks or other business outcomes. Monetization metrics such as revenue and order value are among the metrics documented in the A/B-testing literature.

That is different from saying:

“This particular customer is willing to pay more, therefore charge this customer more.”

The evidence collected here does not establish that kind of individual profiling.

In fact, one of the more important findings from the testing is what cannot be concluded. The observations are consistent with randomized assignment to a pricing experiment. They do not demonstrate that Proton calculated an individual user’s willingness to pay from their identity, browsing history, location or other personal characteristics.

The HTML contains an unusually useful clue

The most important technical artifact is the meta tag:

<meta name="ab-test:VpnHpAndPricingVpnPlusSensibility300726" content="A">

The corresponding B variant is:

<meta name="ab-test:VpnHpAndPricingVpnPlusSensibility300726" content="B">

The name itself is descriptive enough to raise the obvious question.

ab-test explicitly identifies an A/B test.

VpnHpAndPricingVpnPlus appears to refer to the VPN homepage/pricing experience and VPN Plus.

Sensibility is part of the identifier Proton’s page exposes.

300726 is also present, but there is no evidence establishing that it represents July 30, 2026 rather than an internal experiment identifier. It would be speculation to call it a date simply because it resembles one.

The HTML therefore establishes something much narrower and more useful:

The page exposes an experiment identifier and a variant value.

It does not, by itself, establish what the experiment changes.

That requires looking at the rendered page and correlating the value with the actual customer-facing result.

Why a normal HTTP request is not enough

This is where the investigation becomes technically interesting.

The pricing page does not simply return a complete static HTML document containing the final price.

In the captured sessions, the experiment assignment was visible in the HTML source, while the final pricing information was rendered in the browser after the page loaded.

That creates two separate layers of evidence:

HTTP response
     |
     +--> HTML
     |      |
     |      +--> ab-test ... content="A"
     |
     +--> JavaScript/application data
              |
              +--> rendered pricing

A basic command such as:

curl https://protonvpn.com/pricing

can therefore be insufficient for reproducing what a customer actually sees.

A request may retrieve the server-rendered HTML and expose the experiment assignment while failing to reproduce the final browser-rendered price.

The practical consequence is:

The experiment assignment and the displayed price need to be captured from the same browsing session.

If someone retrieves the HTML in one context and then opens the pricing page in another context, they can accidentally associate the wrong price with the wrong variant.

That is why the methodology used here paired the HTML assignment with the rendered pricing page during the same session.

The test conditions

The observations were deliberately kept narrow.

The same device and browser environment were used, with Proton VPN connected through Finland, the currency set to EUR, the two-year term selected, and the session kept signed out. Cache and cookies were cleared between readings. The target was protonvpn.com/pricing. One reading deliberately changed the currency as a control.

The device was a Windows laptop with Edge in a private window and non-private window, with Proton VPN Secure Core and a Finland exit. The important point is not the specific handset. It is that the environment was held constant while the assignment and displayed price were repeatedly observed.

This is not a statistically powered experiment in the academic sense. It is a reproducibility test of a very specific claim:

Does the variant exposed in the page HTML correspond to the price rendered for VPN Plus under repeated loads?

That narrower question can be answered with considerably less data than would be necessary to estimate a conversion-rate effect.

What the two variants displayed

During the documented observation period, two pricing states were observed.

Variant A displayed VPN Plus at €2.99 per month, marked as 70% off from a €9.99 reference price. The page showed a total of €71.76 for the first 24 months, followed by renewal at €83.88 every 12 months.

Variant B displayed VPN Plus at €3.49 per month, marked as 65% off from the same €9.99 reference price. The first 24 months were shown as €83.76, again followed by renewal at €83.88 every 12 months.

That means the difference between the two introductory offers was:

€83.76 − €71.76 = €12.00

The difference was not caused by the recurring price. Both variants converged on the same €83.88 annual renewal amount.

The difference was in the initial 24-month promotional price.

The repeated sequence is the strongest evidence

The recorded sequence was:

B → A → B → A → B

over approximately 74 minutes.

The timestamped readings included B at 06:45:24, A at 07:09:02 during the currency-control reading, B at 07:32:30, A at 07:34:47, and B at 07:59:23. Additional source readings recorded the corresponding meta-tag values, including B at 06:50:41, A at 07:34:36 and B at 08:01:44.

The significance is not simply that two different prices existed.

Different prices at different times can have many explanations. A promotion can expire. A deployment can change. A cache can serve an older version. A pricing database can be updated. A frontend can fail to invalidate old content.

The much stronger observation is that the state repeatedly changed in both directions:

06:45       B
07:09       A
07:32       B
07:34       A
07:59       B
08:01       B tag

A stale deployment normally produces a transition:

old state  --->  new state

The observed behaviour instead looked like:

A ---> B ---> A ---> B

That is exactly the sort of behaviour an experiment assignment mechanism can produce.

It does not prove the complete architecture of Proton’s experimentation system, but it is strong evidence against the simple explanation that one obsolete price was merely waiting for a cache or deployment refresh.

The price arithmetic independently checks out

There is another useful control in the data.

Both variants use the same €9.99 reference price.

For Variant A:

€9.99 × 30% = €2.997

which is displayed as €2.99.

For Variant B:

€9.99 × 35% = €3.4965

which is displayed as €3.49.

The 24-month totals also reconcile:

€2.99 × 24 = €71.76

and:

€9.99 × 24 = €239.76

so the displayed saving is:

€239.76 − €71.76 = €168.00

For Variant B:

€3.49 × 24 = €83.76

and:

€239.76 − €83.76 = €156.00

The numbers therefore form internally consistent pricing variants rather than a collection of unrelated values. The source record documents the same reconciliation.

That matters because it eliminates another possible explanation: that the apparent difference resulted from a malformed price, an arithmetic display error or an unrelated component being rendered incorrectly.

The page is presenting two coherent promotional offers.

The currency control

One reading deliberately changed the currency.

The USD result showed the same numerical promotional price, $2.99, with the 70% discount corresponding to Variant A. The purpose of this control was not to investigate Proton’s currency-conversion system, but to determine whether the observed variation could simply be explained by the selected currency.

It could not. The price state still corresponded to the underlying variant. That leaves the experiment assignment as the more direct explanation for the A/B difference observed in this test.

The strongest control: Proton Unlimited did not change

The most useful part of the investigation is arguably not the VPN Plus price itself.

It is what happened immediately underneath it. The same pricing page also displayed Proton Unlimited. Under both observed variants, Proton Unlimited remained at the same promotional price:

€7.99/month, 38% off, €191.76 for the first 24 months, renewing at €119.88 annually.

The evidence shows the unchanged Proton Unlimited card in the same render where VPN Plus changes.

That makes the stale-content explanation considerably harder to sustain as a complete explanation for the VPN Plus behaviour.

If the entire pricing document were randomly serving old and new promotional content because of caching, there would be no obvious reason for only one product card to alternate while the adjacent product card remained identical within the same document render.

More importantly, the experiment identifier itself contains VpnPlus:

VpnHpAndPricingVpnPlusSensibility300726

and VPN Plus was the product whose introductory price changed.

The evidence therefore shows a coherent relationship between:

experiment assignment
        ↓
VPN Plus promotional state
        ↓
hero price
        ↓
discount percentage
        ↓
24-month billed amount

The other Proton plan remained unchanged.

That is much more consistent with a targeted pricing experiment than with a page-wide stale-cache problem.

The same value propagates through the page

The variation was not limited to a single number on the hero card.

The two-year selector at the top of the pricing page reflected the same 70% versus 65% discount, and the comparison information further down the page carried the corresponding value.

This is technically significant.

A poorly synchronized frontend might display one price in the hero component and another in a comparison component. That is not what was observed.

Instead, the variant appeared to influence the pricing state consistently throughout the page.

Conceptually, the page behaves like:

Experiment assignment
        |
        v
    pricing state
      /     \
     /       \
hero card   comparison data
    |           |
discount      discount
price         price
    \           /
     \         /
       same variant

That coherence is evidence that the variation is being applied at the pricing-data or application-state level rather than being a cosmetic alteration to one HTML element.

It still does not reveal the backend implementation. We cannot responsibly claim whether Proton uses a dedicated experimentation platform, an internal service, an edge worker, a feature-flag system or another mechanism without access to the server-side architecture.

What the browser evidence demonstrates is the observable behaviour.

A second Proton pricing page behaves differently

There is also an important comparison with proton.me/pricing.

The investigation found no ab-test meta tag on that page, with the tag search returning no match in the retrieved source. That page displayed VPN Plus at a different, stable promotional price for the yearly term: €3.99/month at 60% off, billed €47.88 for the first 12 months and then renewing at €83.88 annually.

This does not mean proton.me and protonvpn.com necessarily use different pricing databases. It means that the observed A/B marker was scoped to the Proton VPN pricing page examined here.

The evidence does not establish that Proton has one universal pricing algorithm affecting every Proton property. It establishes that the protonvpn.com pricing experience showed the experiment marker and the two observed VPN Plus states.

Proton’s explanation needs to remain part of the record

A fair investigation cannot remove evidence that points in the opposite direction.

Before the Windscribe thread, Proton’s General Manager responded to users who had reported inconsistent pricing. The response stated that there was no adaptive pricing, that a sale had recently ended and introductory prices were returning to normal, and that some of the prices shown in the screenshots appeared lower than both previous and current prices, suggesting an error on Proton’s side.

That explanation cannot simply be discarded because a competing company later published evidence of an A/B test.

There is also independent evidence that Proton’s web properties can display stale marketing information. On the same date, the captured Proton VPN page advertised more than 20,000 servers in 140+ countries, while proton.me advertised more than 15,000 servers in 120+ countries. The source record treats this as evidence that inconsistent marketing information can exist across Proton properties.

That is a legitimate observation.

But it does not explain the particular sequence observed here.

The question is not whether stale content can exist at Proton. The evidence says it can.

The question is whether stale content explains:

B
A
B
A
B

with the corresponding VPN Plus price changing each time while Proton Unlimited remains unchanged in the same page render. The observed evidence says it does not adequately explain that behaviour.

What the browser state tells us

There was also an earlier public claim that the experiment value was associated with a normal browser session versus a private browsing session.

The repeated tests did not reproduce that behaviour. All of the readings in this investigation were taken in a Private and Non-Private Edge Window, yet both A and B were observed repeatedly. The source record therefore treats the earlier claim that private browsing deterministically produces one particular variant as incorrect.

That does not mean private browsing is irrelevant to every website experiment. It means that, for this particular observation, private mode did not uniquely determine the variant. The more useful finding is that browser state appeared to matter more than the simple distinction between normal and private mode.

The testing record also reports that the assignment persisted across reloads and new private windows within the same state and changed after a full cache and cookie clear. That behaviour is compatible with a client-side or browser-state-linked experiment assignment. It would be irresponsible, however, to turn that observation into a claim about Proton’s exact identity model.

A browser can contain many state mechanisms: cookies, local storage, session storage, cache entries, service-worker state, application state and other identifiers. Without seeing the complete application and network traffic, one cannot determine exactly which mechanism is responsible simply from the final price.

Does this mean Proton is using personal data to set prices?

There is no evidence here that establishes that. This is one of the most important conclusions in the entire investigation. The experiment observed different prices. It observed an explicit A/B-test identifier. It observed the variant value changing. It observed the displayed price changing in lockstep with that value. But none of those observations demonstrate that Proton calculated an individualized willingness-to-pay score for a particular person.

Specifically it’s seen that Finland and Japan exits could produce the same variant within a browser state and concludes that the evidence does not support a claim that the pricing was driven by location or device profiling.

This is particularly important because “dynamic pricing,” “personalized pricing,” “surveillance pricing” and “A/B price testing” are not interchangeable technical descriptions.

Calling this “surveillance pricing” would require evidence that is not present here. Calling it an A/B pricing experiment is much better supported.

What the experiment actually changed

The pricing difference was limited to the initial promotional period.

Variant A:

€71.76 for 24 months

Variant B:

€83.76 for 24 months

Difference:

€12.00

After that initial period, both variants showed the same €83.88 annual renewal price. The source record therefore describes the financial impact as bounded to the introductory purchase rather than a permanent difference in renewal pricing.

That does not make the issue irrelevant. A €12 difference is still a real difference in what two customers can be asked to pay for the same subscription under the same displayed terms. But it does put the finding in its proper scale.

The evidence does not show one customer being permanently placed into a more expensive subscription. It shows two introductory offers that differed by €12 over the initial 24-month period.

If the pricing difference has you reconsidering Proton VPN altogether, our Mullvad vs Proton VPN privacy comparison breaks down how the two providers differ in account anonymity, payment privacy, infrastructure, audits, jurisdiction and advanced privacy features.

Why the experiment is technically identifiable

From a web-application perspective, the architecture visible in the captures makes sense for an experiment.

A simplified implementation could work like this:

Request /pricing
       |
       v
Experiment assignment
       |
       +---- A
       |
       +---- B
       |
       v
HTML contains assignment marker
       |
       v
Browser loads pricing application
       |
       v
Pricing state selected
       |
       +---- A -> 70% -> €2.99 -> €71.76
       |
       +---- B -> 65% -> €3.49 -> €83.76

The exact implementation may be considerably more complicated.

For example, the assignment could be generated server-side and embedded into a bootstrap object. A frontend application could then consume that value and select the appropriate price object. Alternatively, the server could return a variant identifier and a client-side service could request the corresponding pricing configuration.

The captured evidence does not tell us which of those architectures Proton uses.

It does tell us something more useful for an external investigator: the experiment assignment was exposed to the browser, making the variant observable without privileged access.

That is why the meta element matters.

The browser is effectively being told:

Experiment = VpnHpAndPricingVpnPlusSensibility300726
Variant = A

or:

Experiment = VpnHpAndPricingVpnPlusSensibility300726
Variant = B

The price then becomes an observable output of that state.

Why curl alone would produce an incomplete investigation

This is worth emphasizing because it is an easy trap for security researchers.

Suppose a researcher runs:

curl -s https://protonvpn.com/pricing

and searches for:

ab-test

They might find:

<meta name="ab-test:VpnHpAndPricingVpnPlusSensibility300726"
      content="A">

They now know the experiment exists.

But if the actual price is injected or hydrated later, the HTTP response alone does not establish that A means €2.99.

Another researcher might load the browser page independently and see €3.49.

Without session correlation, the two researchers could accidentally associate the wrong values.

The correct workflow is closer to:

Open one browser session
        |
        +--> record source / DOM assignment
        |
        +--> record rendered price
        |
        +--> save timestamp
        |
        +--> preserve browser state
        |
        v
Repeat under controlled conditions

This is a much stronger methodology than simply collecting screenshots from unrelated devices.

The investigation’s eight readings therefore matter less as a large sample and more as repeated paired observations.

What the eight readings prove, and what they do not

The source record reports eight readings with eight matches between the observed variant and the corresponding VPN Plus price. Five of those readings are exhibited with timestamps, while three were recorded during an earlier working session and counted but not included as image exhibits.

That is enough to establish reproducibility of the observed correlation within the test conditions.

It is not enough to establish statistical significance in the formal experimental sense.

A proper analysis of the business experiment would require information unavailable to an outside observer, including the total population exposed to each variant, assignment probabilities, experiment duration, conversion events, revenue, confidence intervals, statistical power, exclusion criteria and potentially sequential-testing methodology.

The eight observations are therefore evidence of a deterministic relationship between the exposed variant and the rendered price during the observation window.

They are not evidence that the pricing experiment itself produced a statistically significant increase in revenue or conversion.

What Windscribe’s evidence adds

Windscribe is a competitor, so its claims deserve appropriate skepticism.

At the same time, dismissing the evidence solely because it came from a competitor would be equally poor methodology.

Windscribe’s August 8 thread identified the same ab-test:VpnHpAndPricingVpnPlusSensibility300726 tag and argued that the two prices represented price-sensitivity testing. The Reddit discussion independently reproduced the tag and discussed the same two-state behaviour.

The value of the present investigation is that it does not depend solely on Windscribe’s screenshots. It tests the actual relationship between the tag and the rendered price. That produces a much narrower and more defensible conclusion:

During the documented observation window, the value of the exposed A/B-test tag predicted which VPN Plus introductory price the browser rendered.

That conclusion does not require accepting Windscribe’s characterization of Proton’s motives.

The part that cannot be responsibly concluded

There are several tempting conclusions that the evidence does not justify.

It does not establish that Proton deliberately lied. It does not establish that Proton violated any law. It does not establish that customers were selected according to personal characteristics. It does not establish that the experiment was based on IP address, nationality, income, browsing history or willingness-to-pay modelling. It does not establish that only two variants existed. It does not establish that the identifier’s 300726 suffix is a date. It does not establish when the experiment began or when it will end. It does not establish who at Proton created or approved it. It does not establish whether the experiment was designed by Proton itself or implemented through a third-party experimentation system. And it certainly does not establish what any individual Proton employee knew about the public claims.

The original investigation explicitly limits its conclusions in essentially these terms, noting that the Windscribe captures show a different price pair and that the observations establish two variants within the particular observation window rather than the complete architecture of the experiment. That limitation is not a weakness in the story. It is what makes the story credible.

There is still an unanswered question about Proton’s explanation

The most interesting unresolved issue is not whether an A/B marker exists. That is now directly observable.

The unresolved issue is how Proton reconciles that marker with its earlier explanation that the inconsistent prices were caused by a sale that had not universally refreshed.

The two explanations make different predictions. If the problem were purely stale promotional content, one would expect old and new states to coexist temporarily and then converge after the relevant caches or systems were refreshed. If the pricing state is controlled by an experiment assignment, repeated requests can legitimately return different variants. The observation window showed the latter behaviour.

At the same time, Proton demonstrably had inconsistent marketing information across its properties, so stale content is not an imaginary failure mode. It exists in the same ecosystem and on the same date. The evidence therefore does not support the simplistic conclusion that “Proton’s explanation is impossible.”

It supports a more precise statement:

The observed repeated A/B assignment and price correlation are not adequately explained by a one-time stale-sale refresh problem alone.

That is a technical conclusion rather than a judgment about intent.

Why this matters beyond Proton

The broader issue is not that websites run A/B tests.

They do, and the research literature describes A/B experimentation as a normal part of modern software development.

The issue is what happens when the thing being tested is the price itself.

Changing a button colour between two groups is usually invisible to the user’s wallet.

Changing the amount charged for the same subscription is materially different.

A pricing experiment can be commercially legitimate. But it also creates a transparency question that does not exist to the same degree when the experiment concerns typography, layout or button placement.

The technical mechanism is still ordinary experimentation:

random assignment
       ↓
different treatment
       ↓
measure behaviour
       ↓
compare outcomes

The treatment simply happens to be price.

That is important because the existence of an A/B test is not itself evidence of misconduct.

The ethical and consumer question is what customers are told about the offer and whether the presentation creates a misleading impression about why the price is different.

Answering that question requires facts beyond the browser evidence collected here.

Proton’s own current pricing documentation adds another useful context

Proton’s current pricing page confirms that its consumer VPN plans are sold across different billing periods and that promotional discounts can apply to VPN Plus. The page also says that after a promotional period, subscriptions renew according to the applicable renewal terms.

Proton’s Terms of Service are even more explicit about renewal mechanics. They state that subscriptions can be billed monthly, yearly or every two years depending on the selected plan, and that after the initial term the subscription renews automatically for the duration specified at purchase unless cancelled or modified. They also state that the price displayed at the time of the initial purchase can change for a later renewal, with the then-current renewal price applying.

That is consistent with what the observed page showed: a discounted introductory term followed by a higher standard renewal amount.

Proton also documents that customers can change plans and that unused time can be converted into account credit when switching between paid subscriptions.

None of that resolves the A/B question, but it helps separate two issues that are easily conflated online.

The higher future renewal price is not the finding.

The finding is the difference between the two initial promotional offers shown for VPN Plus.

The bottom line

The evidence collected on August 8, 2026 supports a straightforward technical conclusion.

On protonvpn.com/pricing, the HTML exposed an A/B-test identifier:

<meta name="ab-test:VpnHpAndPricingVpnPlusSensibility300726" content="A">

or:

<meta name="ab-test:VpnHpAndPricingVpnPlusSensibility300726" content="B">

Repeated browser observations then showed that the variant corresponded to two different VPN Plus introductory prices.

Variant A displayed:

€2.99/month, 70% off, €71.76 for 24 months

Variant B displayed:

€3.49/month, 65% off, €83.76 for 24 months

The difference was €12 over the initial two-year term. Both subsequently renewed at the same €83.88 annual price.

The sequence alternated between the two states during the observation window rather than simply moving once from an old price to a new price.

The VPN Plus price changed while Proton Unlimited remained unchanged in the same page render.

The experiment marker specifically references VPN Plus, while another Proton pricing page did not expose the same marker.

Taken together, those observations are strong evidence that the displayed VPN Plus promotional price was controlled by an A/B variant assignment during the tested period.

What they do not establish is intent.

There is no technical basis here for saying that Proton was using personal information to calculate individual willingness to pay. There is no basis for claiming that the practice was illegal. There is no basis for saying that Proton employees deliberately lied. Those are separate questions requiring additional evidence.

There is also a legitimate piece of contrary evidence: Proton’s web properties demonstrably contained inconsistent marketing information on the same day, showing that stale content can occur.

But that does not explain the central observation: a browser repeatedly receiving A and B assignments, with the corresponding VPN Plus price changing in lockstep while the rest of the pricing page remains stable.

That is the part of the story that survives scrutiny.

The simplest accurate description is therefore not “Proton is secretly charging everyone differently,” and it is not “Proton was definitely lying.”

It is this:

Proton VPN’s pricing page exposed an A/B-test identifier, and repeated controlled observations on August 8, 2026 showed that the identifier corresponded to two different introductory VPN Plus prices, €2.99 and €3.49 per month, producing a €12 difference over the initial 24-month term.

Everything beyond that requires evidence that has not yet been established. In a technical investigation, the strongest finding is not the most dramatic one. It is the one that remains true after the assumptions have been stripped away.