QR-master/.hermes/plans/2026-07-13_151727-qr-master-decision-content-and-market-proof.md

QR Master: Decision-Content + Market-Proof Implementation Plan

For Hermes: Execute only after Timo explicitly asks to implement. Do not create a page cluster before the hub has real search/conversion signals.

Goal: Ship one German decision page for the static vs. dynamic QR code decision, instrument it with existing analytics, then test the exact message with real DACH restaurants/cafés before expanding SEO content.

Architecture: Reuse the existing localized, data-driven use-case route src/app/de/[slug]/page.tsx and UseCasePageTemplate. Add one German content object to src/lib/growth-pages-de.ts; the route already creates static params, self-canonical metadata, hreflang pairs, Breadcrumb/FAQ schema and CTA tracking. Do not touch the English restaurant page: it already owns the restaurant-menu intent at /restaurants, and the old English use-case route redirects there.

Tech Stack: Next.js App Router, TypeScript, existing UseCasePageTemplate, PostHog (MarketingPageTracker / TrackedCtaLink), npm.

---

Current repo facts

• German localized use-cases are generated from src/lib/growth-pages-de.ts:29 through src/app/de/[slug]/page.tsx:14-108.
• The route gives each item a self-canonical and creates static params from the data object (src/app/de/[slug]/page.tsx:14-38).
• The existing template already tracks page views as landing_page_viewed and CTA clicks as cta_clicked (src/components/marketing/MarketingAnalytics.tsx:28-93). Do not create parallel events until the funnel’s actual setup/signup events are located.
• /use-cases/restaurant-menu-qr-codes is a permanent redirect to /restaurants (next.config.mjs:89-92). The /restaurants page already owns English menu/PDF/reprint copy (src/app/(main)/(marketing)/restaurants/page.tsx:34-69).
• No German restaurant/speisekarte page exists in src/lib/growth-pages-de.ts today.

Non-goals

• No ten-page pSEO rollout.
• No bespoke template, calculator, schema type, A/B framework, or new tracking architecture.
• No claim of guaranteed savings, GDPR compliance, or “instant” changes unless product behaviour and legal wording are verified.
• No customer-story or dashboard screenshot presented as proof until it is real.

---

Task 1: Lock the positioning and page boundary

Objective: Ensure this page wins a new decision query instead of competing with generic generator or restaurant-menu pages.

Files:

• No code change.
• Review: src/app/(marketing-de)/qr-code-erstellen/page.tsx:26-87
• Review: src/app/(main)/(marketing)/restaurants/page.tsx:34-170
• Review: next.config.mjs:63-97

Step 1: Adopt the exact target user and job

• Segment: DACH restaurant/café operators with printed table tents, menus, takeaway flyers, or window signs.
• Job: Decide before printing whether a QR destination needs to stay editable.
• Primary query family: statischer oder dynamischer qr code, unterschied statischer dynamischer qr code, qr code link später ändern.
• Explicit exclusion: do not target the generic “free QR generator” query or try to become a restaurant POS/menu-builder page.

Step 2: Define the content angle

Use this hero content:

• H1: Statischer oder dynamischer QR-Code? Entscheide vor dem Druck.
• Intro: Wenn sich dein Link, Menü, PDF oder Angebot später ändern könnte, brauchst du einen QR-Code, dessen Ziel du ohne Neudruck aktualisieren kannst.
• Primary CTA: Dynamischen QR-Code erstellen
• Secondary CTA: Zum QR-Code-Generator

Step 3: Define the one-sentence decision rule

Bleibt das Ziel garantiert unverändert, reicht ein statischer QR-Code. Kann sich Ziel, PDF, Menü, Aktion oder Platzierung ändern, ist ein dynamischer QR-Code die sichere Wahl vor dem Druck.

Acceptance criteria: The page is clearly a decision hub, not another restaurant-menu landing page; it contains the decision within the first viewport.

---

Task 2: Add one localized use-case record

Objective: Publish exactly one data-backed German page at /de/statischer-vs-dynamischer-qr-code through the current route/template.

Files:

• Modify: src/lib/growth-pages-de.ts (inside useCasePagesDe, before the closing object)

Step 1: Add the record shape

Add a UseCasePageContentDe record with:

'statischer-vs-dynamischer-qr-code': {
  enSlug: 'dynamic-qr-code-generator',
  slug: 'statischer-vs-dynamischer-qr-code',
  href: '/de/statischer-vs-dynamischer-qr-code',
  title: 'Statischer oder dynamischer QR-Code?',
  cluster: 'qr-code-basics',
  parentHref: '/dynamic-qr-code-generator',
  parentTitle: 'Dynamischer QR-Code-Generator',
  ctaLabel: 'Dynamischen QR-Code erstellen',
  eyebrow: 'Vor dem Druck entscheiden',
  titleSuffix: 'vor dem Druck',
  metaDescription: 'Statischer oder dynamischer QR-Code? Vergleiche Änderbarkeit, Druckrisiko und Tracking – und entscheide vor Flyer, Speisekarte oder Tischaufsteller.',
  // remaining template fields in the following steps
}

Step 2: Write unique decision content—not token substitutions

Populate the template fields with these content requirements:

• answer: the exact decision rule from Task 1.
• whenToUse: three observable conditions: destination cannot change; a PDF/menu/offer might change; scans must be measured by placement.
• comparisonItems: only concrete trade-offs, e.g. destination after print, response to a changed PDF, scan measurement. Validate the template’s left/right presentation before wording the boolean values.
• howToSteps: create a dynamic code → print it once → change the destination later in the dashboard.
• workflowCards: one realistic café example (30 table tents, new menu PDF), one flyer/event example, one separate-placement tracking example.
• checklist: test print size/contrast, use a descriptive scan CTA, point to a mobile target, keep a dynamic target when it can change.
• supportLinks: /dynamic-qr-code-generator, /qr-code-tracking, /reprint-calculator, /qr-code-print-size-guide after verifying every target resolves.
• faq: 3–4 factual FAQs such as “Kann ich den Link eines statischen QR-Codes später ändern?” and “Wann lohnt sich ein dynamischer QR-Code für eine Speisekarte?”

Step 3: Avoid fictional proof

Set no heroImage unless a real product/dashboard or verified purpose-built illustration exists. If the template needs an image visually, use a clearly labelled product workflow asset—not a fake customer outcome or fabricated dashboard state.

Acceptance criteria: generateStaticParams includes the slug; the page has unique German title, description, H1, intro, FAQ and internal-link context.

---

Task 3: Verify rendered SEO and conversion path

Objective: Confirm the new route is indexable, non-cannibalizing, and sends users into a working generator flow.

Files:

• Verify: src/app/de/[slug]/page.tsx:18-52
• Verify: src/components/marketing/UseCasePageTemplate.tsx:440-526
• Verify: src/app/sitemap.ts

Step 1: Run static checks

Run from repository root:

npm run lint
npm run build

Expected: both commands exit 0.

Step 2: Run the local smoke test

Start the app with npm run dev, then inspect:

• http://localhost:3050/de/statischer-vs-dynamischer-qr-code
• page source/rendered HTML contains one H1
• canonical is https://www.qrmaster.net/de/statischer-vs-dynamischer-qr-code
• page has language alternates generated by buildLanguageAlternates
• primary CTA reaches the German setup/generator flow actually intended for conversion
• all related-resource URLs return a valid page (not redirects to irrelevant pages or 404)
• mobile: H1, decision rule, and primary CTA fit/appear before excessive scrolling; comparison is readable

Step 3: Verify tracking rather than inventing event names

Use the existing PostHog events first:

• landing_page_viewed with landing_page_slug=/de/statischer-vs-dynamischer-qr-code
• cta_clicked with cta_location=hero_primary and this use case slug

Before adding qr_setup_started or signup_completed, locate their real implementation. If no downstream events exist, add them only after documenting the actual generator/signup handoff and preserving no-PII tracking.

Acceptance criteria: build passes, canonical and CTA are correct, events appear in PostHog (or the tracking limitation is explicitly documented), and there is no new page aimed at /restaurants’ restaurant-menu keyword set.

---

Task 4: Run a 7-day manual market test in parallel

Objective: Test whether the language describes a costly current problem, not merely whether people say they like the page.

Files:

• No product code required.
• Create a local working sheet only if Timo asks; do not automate outreach first.

Step 1: Build a 20-prospect list (45 minutes max)

Collect 20 independent restaurants/cafés in one local area. Criteria:

• visible printed menu/table-tent/window QR in Google photos, Instagram, or own site;
• a current menu PDF, ordering page, seasonal offer, or booking link;
• reachable email, Instagram, or contact form.

Step 2: Send 10 short research-first messages

Use this wording, adapted with the venue’s name and observed QR use:

Hi [Name], kurze Frage – ich schaue mir gerade an, wie Restaurants QR-Codes auf Tischaufstellern und Speisekarten nutzen. Musstet ihr den Link, die PDF-Speisekarte oder Preise nach dem Druck schon einmal ändern? Was habt ihr dann gemacht? Ich verkaufe dir gerade nichts; ich will den Ablauf verstehen.

Do not pitch QR Master in the first message.

Step 3: Follow up only with a relevant offer

If they mention an actual recent issue, reply:

Danke, genau diesen Fall untersuche ich. Ich baue ein Setup, bei dem der gedruckte QR-Code bleibt und du nur das Ziel aktualisierst. Wenn du willst, richte ich dir den nächsten Code testweise ein und prüfe vorher kostenlos, ob euer aktueller Code überhaupt update-sicher ist.

Step 4: Record proof, not compliments

For every reply capture: last incident, workaround, print/time cost, current QR tool, decision-maker, and whether they agree to a test/pilot. Strong evidence is a real past case, a follow-up call, a current QR audit, or a pilot—not “klingt gut”.

Acceptance criteria: at least 10 contacts sent and one of these evidence types captured: concrete past incident, audit request, pilot, call, trial, or explicit rejection with reason.

---

Task 5: Make the expansion/kill decision after 7–14 days

Objective: Prevent a content factory before a signal exists.

Decision table:

Signal	Decision
Search impressions/query relevance + CTA clicks	Build exactly one follow-up: /de/qr-code-nach-druck-aendern focused on recovery intent.
At least 2 concrete restaurant incidents or 1 pilot	Improve the restaurant-specific proof/CTA or ship a German restaurant page only after title/canonical mapping against /restaurants.
No relevant queries, replies, CTA clicks, or incidents	Do not create more pages. Change segment/message (e.g. flyers/events/real-estate) and repeat outreach.

Do not expand to flyer, business-card, event, packaging, PDF, and restaurant subpages simultaneously. One successful page/message earns one sibling.

---

Final Definition of Done

1. One live, unique German decision page—not a page cluster.
2. npm run lint and npm run build pass.
3. Canonical, hreflang, CTA and tracking are verified on the rendered route.
4. Ten manual research contacts are sent.
5. A seven-day review contains real proof: Search Console query data, PostHog CTA data, replies, calls, audits, trials, or payments.
6. Only then decide whether /de/qr-code-nach-druck-aendern deserves implementation.