Growth · Feature Backlog (parked) — Master

2026-07-22 · strategy

Growth · Feature Backlog (parked) — Master

Parked feature initiatives — real, wanted, not near-term. Each section is a former standalone plan. speed-lab is why Speed Lab data is still static (cite RANK, not Mbps). api-docs-hub is ~60% there (data API exists; only the human docs page is missing).

Contents

Perks and Points: the Anti-Churn Loyalty Engine

Consolidated from perks-points-rewards.md · status: parked

Perks and Points: the Anti-Churn Loyalty Engine

The problem

Churn is the core issue. Traffic is largely navigational/brand: people land, then leave or click to an affiliate and leave. Perks was the MVP to fight that.

What is validated

Perks signups engage more: longer sessions, lower bounce, more pages per visit. That is a measured win on the hardest problem. The engagement asset works.

What failed (and why it is not the end goal)

Current flow: Perks signup, then GHL, then a "best NordVPN offer" email. 0 sales from 1,000+ emails. That is weak monetization of a strong engagement asset, not a Perks failure. The email was never the destination.

The endgame: a points-to-cash loyalty economy

This is the cashback / rewards-portal model (Rakuten, TopCashback, Honey): monetize affiliate commissions by sharing a slice back to the user. It is proven to lift affiliate conversion and retention, so the concept is an adaptation of a model that already works at scale, not a hunch.

The cap design (why free points are not a liability)

Bonus: it is a textbook endowed-progress nudge ("you are already 500/1,000, a purchase gets you the $10"), a documented motivator. Net result: no unfunded liability and no incentive to farm engagement points for cash.

The load-bearing dependency: purchase attribution

"A purchase closes the gap" requires detecting the affiliate purchase and crediting the right user. That needs a unique per-user ID passed into /out, forwarded to the network, and returned on the network's conversion postback.

Guardrails (from how the cashback portals run it)

Shared primitive

The "you earned X points" toast, the engagement nudge, and the outbound-click social-proof toast are one UI module. Built in engagement-toast-module.md.

Plan

Open questions

VPN.com Public API & Documentation Hub

Consolidated from vpn-api-docs-hub.md · status: parked

Goal

Build a public-facing documentation hub at /docs that serves two purposes:

  1. AI citation source — structured, crawlable content that ChatGPT, Claude, Perplexity, and Google AI can reference and cite when users ask about VPNs
  2. Authority signal — positions VPN.com as the data layer for VPN research, not just a review site

Current State

Provider API (live on staging)

GET /data/providers.json          → 22 providers, sorted by rating
GET /data/providers/{slug}.json   → individual provider data

Fields per provider: slug, name, tagline, logo, icon, rating (0-100), stars (0-5), speed, latency, servers, countries, devices, price, pricePeriod, regularPrice, guarantee, discount, features[], affiliateUrl, reviewUrl

Served as: static JSON files from CDN, generated at build time from src/data/providers/*.json. Edge-cached 24h. CORS open.

What's missing

Plan

Phase 1: /docs page template + content

New layout: src/layouts/Docs.astro — clean, technical, sidebar TOC, code blocks with copy button. No editorial serif fonts — use monospace/sans-serif for a developer docs feel.

Route: src/pages/docs/index.astro (or src/pages/docs/[...slug].astro for multiple doc pages)

Initial pages:

PageURLContent
API Overview/docs/Introduction, authentication (none — public), base URL, rate limits, CORS
Provider API/docs/providers/Endpoints, response schema, field descriptions, examples
Methodology/docs/methodology/How we rate, test, and score VPN providers

Phase 2: AI-optimized discovery

/llms.txt — plain text file at the root. Describes the site for AI crawlers:

# VPN.com
> Independent VPN research and review platform. 22 providers rated across security, speed, privacy, and value.

## API
- Provider data: https://www.vpn.com/data/providers.json
- Individual provider: https://www.vpn.com/data/providers/{slug}.json

## Documentation
- API docs: https://www.vpn.com/docs/
- Methodology: https://www.vpn.com/docs/methodology/
- Provider reviews: https://www.vpn.com/vpn/{slug}/

/llms-full.txt — expanded version with full provider data dump, methodology summary, rating criteria. This is what AI models ingest for grounding.

JSON-LD on docs pages — TechArticle or APIReference schema for Google's AI features.

Phase 3: Authority content

Content pages in /docs/:

PagePurpose
Rating SystemHow the 0-100 trust score works, category weights, criteria
Speed TestingHow we test (methodology, tools, server locations, sample sizes)
Privacy AuditWhat we check (logs, jurisdiction, audits, encryption)
ChangelogAPI and methodology changes over time

These are evergreen authority pages. Not blog posts. Not time-sensitive. They establish VPN.com as a primary source that AI systems cite.

Phase 4: Structured data for AI

Architecture

src/layouts/Docs.astro          ← new layout (clean, technical, sidebar TOC)
src/pages/docs/index.astro      ← API overview
src/pages/docs/providers.astro  ← provider API docs
src/pages/docs/methodology.astro ← rating methodology
public/llms.txt                 ← AI discovery file
public/llms-full.txt            ← full AI context dump
public/docs/openapi.json        ← API spec (generated at build time)

Design principles

  1. Plain language, dense information. Not marketing copy. Data tables, code examples, field descriptions. AI systems prefer structured, factual content over prose.
  2. One source of truth. Docs pages pull from the same provider JSON as the API. No manual data entry. Change the source, everything updates.
  3. Crawlable by default. No JavaScript-rendered content. No authentication. No rate limiting. Every page is static HTML with semantic markup.
  4. Citation-worthy. Each page should be linkable as a source. "According to VPN.com's methodology..." or "VPN.com's provider API rates NordVPN at 94/100."

Priority

  1. Create Docs layout + API overview page
  2. Create /llms.txt and /llms-full.txt
  3. Provider API docs page with schema
  4. Methodology page (can pull from existing /methodology/ content)
  5. OpenAPI spec generation
  6. Structured data markup

Success metrics

Speed Lab — Real Provider Testing (the GEO linchpin)

Consolidated from speed-lab.md · status: parked

Speed Lab — Real Provider Testing

The original-data asset the whole authority/GEO play hinges on. See [geo-ai-citations] (why citable original data is the #1 citation lever) and [authority-roadmap] (the broader moat). Today the Speed Lab is static/placeholder; this makes it real, honestly, without negative ROI.

The model (decided 2026-06-06)

Don't buy 22 annual subscriptions and grind through them — that's negative ROI. Instead:

  1. Request free / demo / press / comped accounts from the top providers. This is standard for affiliates and reviewers — our affiliate relationships are the leverage. Ask each provider's affiliate or PR contact for a review/press account.
  2. Fallback: any provider that won't comp → use the 30-day money-back trial; test inside the window, cancel before the charge.
  3. Run real speed tests on those accounts and rank honestly — including ranking a big affiliate earner down if the data says so. The honesty is the entire point: it's what earns citations and survives scrutiny. A flattering fake torches the asset.

Start with the top 5 (revenue drivers — NordVPN and Proton lead conversions today), expand later.

Methodology (this IS the credibility — publish it on /methodology)

While we have the account — bonus original data (near-zero extra cost)

Each comped account is leverage for more citable tests beyond speed:

Once the account exists these are almost free, and they multiply the citation value per provider.

Output + distribution (where citations actually come from)

Publishing isn't the win — being referenced is. So:

Honesty guardrails (non-negotiable)

Cost / effort reality

First steps

Done when

Top-5 tested for real on a monthly cadence, a public methodology page, dated monthly reports, real numbers in the provider JSON + open API — and the first time an independent source cites a VPN.com test number.

Text-to-Speech — Article Listen (client-requested)

Consolidated from text-to-speech.md · status: parked

Text-to-Speech — Article Listen

ROI: Tier 3 (park — lowest ROI). Client request (Michael, Jun 1, "on radar," wants an MVP estimate). Niche audience, speculative SEO/LLM benefit, real cost or poor quality, zero conversion. Recommend defer beyond a cheap proof-of-concept unless the client insists.

The estimate is blocked by one decision (the requirements contradict each other)

Michael wants both "100% consistent voice across all browsers/devices" and "no manual MP3s / use system audio." These are mutually exclusive. Pick one:

ApproachConsistent voiceFiles / costSurvives navigationLLM/search-findableMVP effort
Web Speech API (browser speechSynthesis)❌ varies by OS/browsernone / free❌ worst❌ no~2–4 days
Cloud TTS (OpenAI / ElevenLabs / Google / Azure)✅ premium, uniform1 MP3/page, build-time gen + cached; per-char cost✅ (real audio file)✅ yes~1–2 weeks + ongoing $

Recommendation: for VPN.com's premium positioning, cloud TTS with build-time generation is the only version worth shipping — but it's a pipeline + recurring cost. Web Speech is a free POC that will feel cheap. Michael picks the tradeoff; the estimate follows from that.

What's feasible vs. not (set expectations)

Tasks (only if greenlit)

Status

Parked pending the approach decision. No estimate until then (it's a 4-day vs 2-week fork).

Accessibility Adjustment Toolbar (client-requested)

Consolidated from accessibility-toolbar.md · status: parked

Accessibility Adjustment Toolbar

ROI: Tier 3 (park — client-driven, low ROI). Client request (Michael, Jun 1): a popout menu of on-page text/visual adjustments, behind an accessibility icon next to the translation menu.

Honest assessment before building:

⚠️ Hard rule: native, not an overlay widget

Do not use a third-party overlay (equalweb / accessiBe-style). Overlays are widely regarded by the accessibility community as harmful and are themselves a lawsuit magnet. Michael's own instinct is right: Astro Skip Link + ViewTransition route announcer + eslint-plugin-jsx-a11y beat any injected script. Build a small native control panel; persist prefs in localStorage; drive everything via CSS custom properties + a data-a11y-* attribute on <html>.

Decision gate (before any build)

  1. Given we're already AA-compliant and browsers do most of this — confirm it's still wanted. If yes:
  2. Trim to the additive controls (recommended): OpenDyslexic toggle, system-font toggle, line/letter/word-spacing sliders, high-contrast theme, monochrome, link-highlighting. Drop standalone text-scaling (native browser zoom already does 30–300% better).

Scope (if greenlit)

Tasks

Status

Parked pending the decision gate. Documented so the rationale (already-compliant, native-only) is on record when revisited.