DEV Community: Yuto Tanaka

How to A/B Test Two Landing Pages Using Campaign Links

Yuto Tanaka — Fri, 16 Oct 2026 00:01:00 +0000

You have two landing pages and one campaign link. You want to know which page converts better without sending half your traffic to a page you haven't tested. The usual answer is an A/B test, but the mechanics of routing a single campaign link to two destinations and then measuring the result are less obvious.

This article covers a practical setup: a stable campaign URL that redirects visitors to variant A or B, assigns each visitor consistently, and passes the variant through to your analytics. The code is small; the discipline is in consistent assignment and clean measurement.

The routing problem

A campaign link is the URL you put in ads, emails, social posts, or QR codes. If you change that URL for every experiment, you lose attribution and break links that people have already shared. So the campaign link should stay stable, and the decision about which landing page to show should happen behind it.

The simplest architecture:

Campaign link (short or long) points to a redirect endpoint, e.g. https://example.com/campaign.
The redirect endpoint assigns a variant and sends a 302 to the matching landing page.
The landing page records the variant and reports conversions.

This keeps one public URL while you test behind the scenes.

Assignment: random once, then sticky

The most common mistake is assigning a variant on every page load. If the same visitor sees page A, then page B on refresh, your data is noisy and the user experience is confusing.

You want sticky assignment: once a visitor is assigned to A or B, they see that variant for the duration of the test. A first-party cookie is the simplest way to do this.

On first visit, pick a variant at random and set a cookie. On later visits, read the cookie and use the same variant.

const LANDING_PAGES = {
  a: 'https://example.com/landing-a',
  b: 'https://example.com/landing-b',
};

function getVariant(request) {
  const cookieHeader = request.headers.get('Cookie') || '';
  const match = cookieHeader.match(/ab_variant=(a|b)/);
  if (match) return match[1];
  return Math.random() < 0.5 ? 'a' : 'b';
}

export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname !== '/campaign') {
      return new Response('Not found', { status: 404 });
    }

    const variant = getVariant(request);
    const destination = new URL(LANDING_PAGES[variant]);
    destination.searchParams.set('variant', variant);

    const response = Response.redirect(destination.toString(), 302);
    response.headers.set('Cache-Control', 'no-store');

    const existingCookie = request.headers.get('Cookie') || '';
    if (!existingCookie.includes('ab_variant=')) {
      response.headers.append(
        'Set-Cookie',
        `ab_variant=${variant}; Path=/; Max-Age=2592000; SameSite=Lax`
      );
    }

    return response;
  },
};

A few details matter here:

302 (temporary) instead of 301 (permanent) so browsers and proxies do not cache the redirect permanently.
Cache-Control: no-store on the redirect response so a CDN does not serve the same variant to everyone.
Appending ?variant= to the destination makes the variant available to client-side analytics without reading cookies.

If you use cookies, check your privacy requirements. A first-party, non-tracking cookie that only stores a or b is usually fine, but it should be covered by your cookie policy. If you cannot use cookies, a fallback is hashing a combination of IP and user agent, but that is less stable and can misassign visitors on shared networks.

Passing the variant to analytics

The A/B test is only as good as its measurement. You need to know which variant each conversion belongs to.

The easiest approach is to read the variant query parameter on the landing page and send it to your analytics tool as a custom dimension or event property.

const params = new URLSearchParams(window.location.search);
const variant = params.get('variant') || 'unknown';

analytics.track('Landing Page View', { variant });

analytics.track('Signup', { variant });

If you use Google Analytics 4, set the variant as a user property or include it in the event parameters. In Plausible or Fathom, you can pass it as a custom property. The exact API depends on your tool, but the idea is the same: every event tied to the experiment carries the variant.

Do not rely on URL parameters alone if users can navigate away and come back. Either set the cookie on the redirect (as above) or set a cookie on the landing page from the query parameter, so the variant persists across page views.

Common pitfalls

Client-side redirects cause flicker. If you assign the variant with JavaScript after the page loads, the visitor may briefly see the wrong page. Server-side or edge redirects happen before any HTML is rendered.

Bots skew the results. Crawlers and monitoring tools often follow redirects. You can exclude known bot user agents from assignment, or simply filter them out in analytics. Either way, know that your raw traffic numbers include non-humans.

Stopping too early. A/B tests need enough conversions to distinguish a real difference from noise. If you have low traffic, you may need to run the test for weeks. Use a sample size calculator before you start, and don't peek at the results every hour.

Testing during a seasonality spike. If you run variant A during a sale and variant B after it, you are measuring time, not the landing page. Run both variants simultaneously.

Forgetting noindex. Landing pages used in a test should have <meta name="robots" content="noindex"> so search engines don't index two near-duplicate pages. The redirect endpoint should also not be indexed.

Keeping the campaign link shareable

A redirect endpoint like https://example.com/campaign is fine, but it may be long, especially if you add tracking parameters. A short link can make the campaign URL easier to paste into ads, social bios, or QR codes.

You can point a short link at your assignment endpoint. For example, a short link service like LinkBit can give you a compact URL that redirects to https://example.com/campaign. The edge function still handles variant assignment; the short link just makes the entry point cleaner to share.

One caution: if a short link service offers its own A/B or split-testing feature, don't layer it on top of your own assignment logic unless you have verified how the two interact. Duplicate splitting can break sticky assignment and make the data harder to interpret. Keep the experiment logic in one place.

What to measure

For each variant, track:

Visitors assigned: how many people entered the test.
Conversions: the action you care about (signup, purchase, demo request).
Conversion rate: conversions divided by visitors.
Time to conversion: useful if the decision is not immediate.

Compare conversion rates, but also check whether the variants differ in bounce rate, scroll depth, or other engagement signals. A page that converts slightly better but has a much higher bounce rate may not be the winner you think it is.

Wrapping up

A/B testing two landing pages with one campaign link comes down to three things:

A stable campaign URL that redirects to the variant.
Sticky, random assignment stored in a cookie.
Clean analytics that carry the variant through to conversion.

The code is a few dozen lines. The harder part is resisting the urge to change the test midway, and making sure your measurement is as reliable as your routing.

ABTesting #WebDevelopment #EdgeComputing #Analytics #LandingPages

Where to Place a QR Code on a Brochure—and What to Write Beside It

Yuto Tanaka — Wed, 30 Sep 2026 06:30:00 +0000

A brochure QR code needs to answer two questions before anyone scans it: What will I get, and can my phone read this comfortably?

Placement solves the second problem. The text beside the code solves the first. For developers preparing brochures for a product demo, conference booth, or technical workshop, treat both as part of the interface.

Put the code where the reader decides to act

Choose the destination first, then place the QR code beside the content that makes that destination useful.

Reader’s next step	Suitable placement	Suggested label
Try a product	Beside the demo description or final call to action	“Scan to open the interactive demo”
Follow an implementation guide	Beside the setup overview	“Scan for the installation guide”
Register for a workshop	Beside the date, venue, and registration details	“Scan to register for the workshop”
View a code sample	Beside the relevant technical example	“Scan to view the sample repository”

A back panel works well for a general next step, such as booking a demo. It is less useful when the code explains a specific diagram buried inside the brochure. In that case, keep the diagram, label, and code together.

For a tri-fold brochure, check the actual folded reading sequence, not just the order of panels in your design file. Print a rough copy and fold it. Confirm that the code appears on the panel you intended and that its explanation is visible at the same time.

Avoid putting essential next steps on a panel readers are unlikely to unfold.

Keep it away from folds, trim edges, and visual noise

Give the QR code its own stable, uncluttered area.

Do not straddle a fold. A crease can distort the pattern or make it difficult to hold flat.
Keep it inside the printer’s safe area. Trim tolerances vary; use the print provider’s specifications rather than assuming a universal margin.
Avoid photographs and textured backgrounds. A solid light background with dark modules is a reliable starting point.
Do not crowd it with labels or icons. The blank border is part of the code’s scanning requirements.
Consider how people hold the brochure. A code at a lower corner may be covered by a thumb.

For a standard QR Code, preserve a quiet zone at least four modules wide on every side. A module is one small square in the pattern. Keep text, borders, and artwork outside that zone.

The quiet zone and the print safe area serve different purposes: one helps decoding; the other protects content from trimming. You need both.

Size the printed code, not just the image file

There is no single minimum physical size that guarantees scanning. Reliability depends on pattern density, print quality, contrast, lighting, camera performance, and scanning distance.

For a handheld brochure, a code around 25–30 mm square, plus its quiet zone, can be a useful prototype size. It is a starting point to test, not a production guarantee. Dense codes or longer scanning distances may need more space.

Developer-friendly checks:

Keep the encoded value reasonably short. Longer values can require more modules, making each module smaller at the same printed size.
Export as vector artwork when your print workflow supports it. SVG or a suitable vector PDF avoids raster scaling artifacts.
If using a raster image, avoid blur and smoothing. Check it at its final placed size; nominal DPI alone does not guarantee readable modules.
Do not assume higher error correction fixes poor layout. It can increase symbol density and does not replace adequate size, contrast, or a quiet zone.

If you choose a shortened destination, a service such as LinkBit can shorten the URL before you generate the QR code. That may reduce the encoded payload, but it also introduces a redirect dependency. Confirm the final destination and plan for the link to remain usable throughout the brochure’s lifetime.

Write the benefit beside the code

“Scan me” describes the interaction, not the reason to do it.

Use this pattern:

Scan to + specific action or resource + relevant expectation.

For example:

“Scan to try the browser demo—no installation required.” Use only if that is true.
“Scan for the Python quickstart and sample project.” Better than “Learn more” when those are the actual resources.
“Scan to book a 15-minute technical walkthrough.” Appropriate when the destination is a booking page.
“Scan to download the specification PDF.” Makes the destination format clear.

Mention friction when it matters: account requirements, paid registration, or a download rather than a webpage. A reader should not discover a materially different task after scanning.

Keep the label next to the code, with enough separation to preserve the quiet zone. If scanning is optional, include a readable fallback address outside that zone. Use a genuine, working address—not an illustrative placeholder in the final artwork.

Test the complete printed interaction

A QR image that scans on a monitor has not passed a brochure test.

Before approving the print run:

Print at 100% of the intended physical size, without “fit to page” scaling.
Fold the brochure and scan it while holding it naturally.
Try more than one phone under ordinary indoor lighting.
Check the finished stock or proof where possible; glossy reflections can interfere with scanning.
Confirm that redirects resolve and the final page uses a valid HTTPS connection.
Test the destination on mobile, including forms, downloads, and any login requirements.
Verify that the label accurately describes what opens.

If you include several QR codes, give each a distinct purpose and label. For a single next step, one well-placed code is usually clearer than repeating it across every panel.

The final check is simple: can someone understand the offer, scan without rearranging the brochure awkwardly, and reach the promised resource? If not, fix the placement, label, or destination before adding more visual styling.