DEV Community: Yuto Tanaka

Client Branded Links Stopped Working After a DNS Change: What to Check

Yuto Tanaka — Sun, 01 Nov 2026 17:28:00 +0000

A branded short link can look like a DNS problem when it is actually a TLS problem, and vice versa. After a nameserver change, a CDN migration, or a zone edit, links.client.com may fail to resolve, resolve to the wrong target, return a certificate error, or redirect to a default page. The fastest way to narrow it down is to check the layers in order: authoritative DNS, TLS, HTTP redirects, and the link service's domain settings.

This checklist assumes the client controls client.com and uses a subdomain such as links.client.com for branded links. The same sequence works for an apex domain, but the DNS constraints are different, so that case gets its own note.

Start with the authoritative DNS answer

Do not begin in the browser. Browser caches, OS caches, and public resolver caches can all hide the current state. Query DNS directly.

dig +short links.client.com
dig +short links.client.com CNAME
dig +short links.client.com A
dig +short links.client.com AAAA

What you want to see depends on how the link service is set up:

A CNAME pointing to the provider target, usually with a trailing dot such as links.provider.example.. The trailing dot is normal in DNS output.
An A or AAAA record if the provider uses CNAME flattening, a proxy, or a direct IP target.
No conflicting records at the same name. A CNAME cannot coexist with an A, AAAA, TXT, or other data at the same owner name.

If dig returns a CNAME but no final address, follow the target. The provider target may be missing, misspelled, or itself broken. If it returns an old IP address from before the migration, the zone change may not have been applied where you think it was.

Check the delegation, not just the record

A common failure is updating records at the old DNS host while the domain is delegated to different nameservers. Look at the delegation and the path resolution takes.

dig NS client.com +short
dig +trace links.client.com

dig NS shows the nameservers currently advertised for the zone. If those are not the ones you edited, the records you changed are irrelevant. Update the registrar or the active DNS provider instead.

dig +trace shows where resolution diverges: at the root, the TLD, the zone's nameservers, or the final target. It is especially useful when one resolver gives the right answer and another gives an old one. If you see SERVFAIL and DNSSEC is enabled, check that the DS record at the registrar matches the new DNS provider. A DNSSEC mismatch can make the whole zone fail even when the records themselves look correct.

Handle apex domains differently

If the branded host is the apex, such as client.com rather than links.client.com, a normal CNAME is not valid alongside the NS and SOA records every zone needs. Some DNS providers offer ALIAS, ANAME, or CNAME flattening at the apex; others require A and AAAA records, or a redirect at the HTTP layer.

Do not assume the provider's flattening behavior is visible in the dashboard. Check what public resolvers actually return:

dig +short client.com CNAME
dig +short client.com A
dig +short client.com AAAA

If the answer changes depending on the resolver, or if the provider returns a mixture of records, treat that as a configuration problem rather than a propagation delay. Also check that a TXT or verification record was not removed when the CNAME was added.

Check TLS before blaming the redirect

DNS can be correct and the link can still fail at HTTPS. A new CDN or reverse proxy may answer for the hostname but not have a certificate that covers it.

curl -Iv https://links.client.com/abc 2>&1 | sed -n '1,40p'
openssl s_client -connect links.client.com:443 -servername links.client.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Check three things:

The certificate is valid for links.client.com, not only for the provider's default hostname.
The certificate chain is complete.
The server negotiates TLS with the correct SNI name. openssl s_client with -servername tests that directly.

If the DNS target changed to a CDN, the CDN usually needs the custom hostname added and validated before it will serve the right certificate. If the site uses HSTS, a broken HTTPS response will not fall back to HTTP; the browser will fail hard. Test with curl first so you see the actual error instead of a browser-generated message.

Follow the full redirect chain

A branded short link is usually a redirector. DNS gets the client to the redirector; the redirector then sends the client to the destination. Both halves can break.

curl -sS -o /dev/null -w '%{http_code} %{url_effective}' https://links.client.com/abc
curl -sS -o /dev/null -w '%{http_code} %{url_effective}' -L https://links.client.com/abc

The first command shows the first response. The second follows redirects and prints the final URL. Check for:

A 301, 302, 307, or 308 to the expected destination.
A redirect loop between HTTP and HTTPS, www and non-www, or two hostnames.
A path or query string that is dropped during the redirect.
A redirect to a default page, which often means the hostname is recognized but the short-link path is not.

While testing, prefer temporary redirects over permanent ones if you control the redirect layer. Browsers cache 301 and 308 aggressively, and a bad permanent redirect can keep failing after DNS is fixed. Clear the browser cache or test with curl from a clean environment.

Test the Host header and application routing

If DNS points to the right server but the response is a generic 404, 403, or default site, the server may not recognize the hostname. Test the IP directly with the expected Host header.

curl -I http://<new-ip>/abc -H 'Host: links.client.com'

If that returns the link, DNS is doing its job and the problem is in virtual-host, TLS, or proxy routing. For an nginx-style reverse proxy, the relevant configuration usually looks like this:

server {
    listen 443 ssl;
    server_name links.client.com;

    location / {
        proxy_pass http://link-service.internal;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The exact configuration depends on the stack. The point is to verify that the hostname reaches the application, not just the server's IP address. A missing server_name, a missing certificate, or a proxy that rewrites the Host header can all produce symptoms that look like DNS failures.

Check the link service's domain state

DNS only routes traffic. The link shortener or redirect service also has to recognize the branded hostname. Check its domain settings for the hostname status, verification records, certificate status, and any default destination or path prefix.

Depending on the service, a domain may need a TXT record, a CNAME, or both before it becomes active. If the domain was removed, left pending, or re-added under a different project, links on that host may return a 404 or fall back to a generic page even though DNS resolves correctly. This is a configuration layer, not a DNS layer, and it is easy to miss after a migration.

To separate a client-domain problem from a general outbound-network problem, test a short URL on a different host from the same machine, such as LinkBit. If that resolves and redirects while links.client.com does not, focus on the client hostname, its certificate, and its link-service configuration.

Account for TTLs and negative caching

If the hostname returned NXDOMAIN or SERVFAIL during the change, resolvers may cache that negative answer. Fixing the record does not always make the error disappear immediately. Check the zone's SOA and query multiple public resolvers.

dig links.client.com SOA
dig @1.1.1.1 links.client.com
dig @8.8.8.8 links.client.com

Also check from outside the client's network. Split-horizon DNS can make an internal resolver return an old internal address while public resolvers return the new target. If the link works in the office and fails for customers, internal DNS is a likely difference.

Before future changes, lower the TTL on the branded hostname well in advance. Keep the old target alive until the TTL has expired, and avoid changing nameservers and records at the same time unless you can watch both layers closely.

Mistakes that look like DNS failures

Updating records at the old DNS provider after the domain was delegated elsewhere.
Adding a CNAME and an A record at the same name.
Using a plain CNAME at the apex without provider flattening.
Pointing DNS at a CDN but not adding the custom hostname or certificate there.
Forgetting to recreate a verification TXT record after a zone migration.
Testing only from an internal network with split-horizon DNS.
Trusting a browser after a permanent redirect has been cached.
Changing DNSSEC settings without matching the DS record at the registrar.

The order that saves time is authoritative DNS first, then TLS, then redirects, then the link service's domain state. If the authoritative answer is right and the certificate is valid, the problem is rarely still DNS. It is usually the layer that was changed next.

DNS #WebDev #DevOps #Troubleshooting #Networking

How to Track Google Ads Traffic to Amazon Listings with Amazon Attribution

Yuto Tanaka — Sun, 01 Nov 2026 17:25:10 +0000

Amazon detail pages don't run your JavaScript. There's no Google Ads conversion tag you can drop onto an ASIN, and no gtag call after Add to Cart. If you send paid traffic from Google Ads to an Amazon listing, the conversion happens on a page you don't own, which is the exact problem Amazon Attribution exists to solve.

This is a wiring problem.

You need a tagged Amazon URL, a click path that doesn't mangle it, and a campaign structure that lets you join Amazon's conversion data back to Google Ads spend.

How Amazon Attribution actually measures a click

Amazon Attribution works on a link, not a pixel. You create a campaign, ad group, and creative inside Amazon Attribution, and Amazon issues a URL for the target ASIN with a maas parameter attached:

https://www.amazon.com/dp/B0C1234XYZ?maas=maas_adg_api_9876543210&ref_=aa_maas

When a user lands on Amazon with that parameter, Amazon records a click against the matching creative. Subsequent events (detail page views, add-to-cart, purchases, units, sales) get attributed to that creative inside Amazon's attribution window. (Check the current Amazon Attribution documentation for the window length; it has historically been 14 days for clicks.)

Two implications for engineers:

The maas value is the entire identity of the click. Lose it and the visit becomes an unattributed organic session.
You never see the click on your side. Amazon doesn't call your endpoint back with a conversion, so your only join key is the campaign / ad group / creative structure you build on both platforms.

Don't hand-construct the maas ID. Copy it from the Attribution console, or generate it through the Amazon Ads API, which exposes Attribution campaign, ad group, and creative resources along with reporting.

Prerequisites you can't route around

An Amazon Ads account with Amazon Attribution access (sellers generally need Brand Registry; vendors get access through Vendor Central).
The tag and the listing must live in the same marketplace. An amazon.com tag pointing at amazon.co.uk will not attribute.
Google Ads auto-tagging on, if you want gclid for cross-checking click volume later.

Wire the tag into Google Ads

There are two ways to get the maas parameter onto the click.

Option A: tagged URL as the final URL. Paste the full tagged Amazon URL into the ad's final URL. It works, and it's the fastest thing to ship. The downside: you get no visibility into your own click path, and every ad carries a long parameterized URL that's easy to break when someone copies it without thinking.

Option B: tracking template plus a redirect you control. The final URL stays the clean listing URL; the tracking template points at your own endpoint, which logs the click and 302s to the tagged URL.

https://track.example.com/go/us-brand-search?campaignid={campaignid}&adgroupid={adgroupid}&creative={creative}&gclid={gclid}&lp={lpurl}

Then a minimal handler:

import express from "express";

const app = express();

// maas tags issued by Amazon Attribution — one per creative you want to measure.
const MAAS_BY_KEY = {
  "us-brand-search": "maas_adg_api_9876543210",
};

app.get("/go/:key", (req, res) => {
  const maas = MAAS_BY_KEY[req.params.key];
  const lpurl = req.query.lp;

  if (!maas || typeof lpurl !== "string") return res.sendStatus(400);

  // Do not turn this into an open redirect.
  const target = new URL(lpurl);
  if (target.hostname !== "www.amazon.com") return res.sendStatus(400);

  // Express already decoded the query value; searchParams.set() re-encodes once.
  target.searchParams.set("maas", maas);
  target.searchParams.set("ref_", "aa_maas");

  console.log(JSON.stringify({
    key: req.params.key,
    gclid: req.query.gclid,
    campaignId: req.query.campaignid,
    ts: Date.now(),
  }));

  res.redirect(302, target.toString());
});

app.listen(3000);

Rules that matter here:

Use 302, not 301. A permanent redirect gets cached by the browser and you lose clicks you can't see.
Keep the chain to one hop. Every extra redirect adds latency before the Amazon page starts loading, and each hop is another chance for a proxy to strip unknown query parameters.
{lpurl} arrives percent-encoded as a parameter value, and Express decodes it for you. Don't call decodeURIComponent a second time. A double decode corrupts any % sequence in the original URL and can produce a mangled query string.
If you're appending the tag by hand and the destination already has a query string, use &, not ?. A second ? silently truncates everything after it.

Use campaign structure as your join key

Amazon Attribution reports break down by campaign → ad group → creative. Google Ads reports break down by campaign → ad group → ad. Mirror them one-to-one and the join becomes trivial:

Google Ads	Amazon Attribution
Campaign	Campaign
Ad group	Ad group
Ad	Creative

Give each level a stable, machine-readable name (such as gads-us-brand-exact or gads-us-brand-exact-b0c1234xyz) rather than "Test 2" and "Test 2 copy". You'll be joining CSVs in a script or a spreadsheet, and descriptive names are the difference between a five-minute join and an afternoon of guessing which row is which.

Validate before you scale

Click your ad (or hit the tracking URL directly) in a normal browser with DevTools open, and confirm the redirect chain ends on Amazon with maas intact.
Check the Attribution console for the click within a few hours. Clicks usually land faster than conversions.
Cross-check Google Ads click counts against Amazon Attribution clicks after a day. They will not match exactly: Google filters invalid traffic, Amazon filters too, and some users never finish the redirect. Large gaps point at a broken tag; small gaps are normal noise.

Failure modes worth knowing

A tag can be stripped by an intermediary. URL shorteners, link cleaners, and some ad platforms drop parameters they don't recognise. Test every hop you introduce.
Amazon may route a click to a different ASIN than the one you tagged for size or colour variants. Attribution still works, but your expected-ASIN report won't line up.
Amazon's app-link handling can open the listing inside the app. Parameter behaviour there isn't under your control, so judge mobile performance by reported numbers rather than by a desktop click test.
Ad blockers and privacy extensions can block long parameterized redirect chains more often than a plain Amazon link.
Wrong marketplace: covered above, and still the most common cause of "no data at all".

Joining spend to conversions

Pull the Amazon Attribution report on a schedule (console export or Ads API), pull spend and clicks from the Google Ads API or a scheduled report, and join on date plus campaign name. The numbers you actually want are cost per detail page view, cost per purchase, and ROAS by campaign. Google Ads can never produce those figures for an Amazon destination because the conversion simply isn't visible to it.

One note on link length

If a tagged Amazon URL needs to live somewhere a 150-character parameterized link is awkward, such as a QR code on packaging, a slide, or a bio link, shorten the full tagged URL rather than the plain listing, then verify the maas parameter survives the redirect before you print or ship anything. LinkBit is one option for that.

The discipline stays the same regardless of tooling: one tag per ad, a click path you control, a naming scheme that survives a CSV join, and a click test after every change to the chain.

How to Disclose Affiliate Links in Social Posts When Using Short URLs

Yuto Tanaka — Sun, 01 Nov 2026 11:44:00 +0000

A short URL does two jobs at once: it makes a link fit a character limit, and it hides where the link goes. The first job is why you use it. The second is why disclosure gets harder the moment you swap a raw affiliate URL for a shortened one, and that part is easy to forget when you post from a script instead of by hand.

The disclosure has to move into the post itself, and there are three ways to make sure it gets there: a text convention, an interstitial redirect that shows the disclosure before forwarding, and a CI check that fails the build when an affiliate link goes out unlabelled.

The disclosure signal a short URL deletes

A raw affiliate URL usually announces itself:

https://shop.example.com/pricing?plan=team&ref=yourname&utm_source=social

The ref= parameter is a tracking leak, but it does tell a careful reader that something is going on. Replace that URL with https://sho.rt/spring-sale and the signal is gone. The reader sees an opaque code and a domain they may not recognise.

Two other things disappear at the same time:

rel attributes. On a blog you can mark an outbound link rel="sponsored nofollow". Social posts are plain text; there's no HTML to attach it to, and the platform may rewrite or re-shorten your URL anyway.
The destination domain. Hovering a short link in a desktop client may show the short domain rather than the final page. On mobile there's nothing to hover.

The underlying requirement doesn't change. The FTC's Endorsement Guides (16 CFR Part 255) call for a clear and conspicuous disclosure of material connections; the UK's ASA/CMA rules take a similar line, and other jurisdictions have their own. In practice that means the disclosure has to be visible in the post itself, next to the link, in words a normal person reads as "this is an ad". Search-engine qualification via rel="sponsored" is a separate concern and does nothing for a reader deciding whether to tap.

Pattern 1: put the disclosure in the post text, before the link

This is the baseline. Everything else is a supplement to it.

Ad: I moved our schema migrations to Example and wrote up what broke.
https://sho.rt/spring-sale

A few conventions that hold up in practice:

Lead with the label. Use anything unambiguous: Ad:, #ad, Affiliate link:. A label at the start gets seen; a hashtag buried in a block of tags does not.
Put it before the link, not after. The reader should know what the link is before they commit to tapping it.
Don't outsource it to your bio or a reply. A disclosure the reader has to go looking for isn't conspicuous.
Don't let a hashtag block carry it. #ad #dev #node #typescript reads as keyword stuffing, and the one meaningful tag disappears into the noise.

Pattern 2: make the short link show the disclosure itself

If you own the redirect, you can render a small disclosure page instead of forwarding instantly, and only forward when the visitor clicks through.

// links.js
export const links = new Map([
  ["spring-sale", { destination: "https://shop.example.com/pricing?ref=yourname", affiliate: true }],
  ["docs", { destination: "https://shop.example.com/docs", affiliate: false }],
]);

// server.mjs
import express from "express";
import { links } from "./links.js";

const app = express();

app.get("/:code", (req, res) => {
  const link = links.get(req.params.code);
  if (!link) return res.status(404).type("text").send("Unknown link");

  if (!link.affiliate) return res.redirect(302, link.destination);

  res.set("X-Robots-Tag", "noindex");
  res.type("html").send(`
<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="robots" content="noindex">
    <meta property="og:title" content="Affiliate link">
    <meta property="og:description" content="This is an affiliate link. I may earn a commission if you buy through it.">
    <title>Affiliate link</title>
  </head>
  <body>
    <main>
      <p><strong>Affiliate link.</strong> If you buy through this link I may earn a
      commission. The price you pay is the same.</p>
      <p><a href="${link.destination}" rel="sponsored nofollow noopener">Continue</a></p>
    </main>
  </body>
</html>`);
});

app.listen(3000);

Notes on the implementation:

Escape link.destination before interpolating it into HTML, or build the page with a template engine that escapes by default. The snippet above is short enough to read but not safe for untrusted input.
Don't auto-redirect with <meta http-equiv="refresh">. An interstitial that forwards after zero seconds is a redirect with extra steps; the whole point is that the person sees the disclosure.
Keep rel="sponsored nofollow" on the outbound anchor. Inside your own HTML it's the one place the machine-readable signal still exists.
Set noindex. A thin disclosure page shouldn't compete with the destination in search results.

The trade-off is an extra tap, which costs you some clicks. If the link is the entire point of the post, pattern 1 is usually enough. Use the interstitial when the link travels on its own: in a bio, a newsletter, a QR code, anywhere the surrounding text may not follow it.

Pattern 3: check what the preview card says

Most social clients turn a posted URL into a preview card. If the card is what people see, the disclosure has to be in it. The og:title and og:description in the snippet above do that for the interstitial page. If the preview fetches the destination directly, you can't control the wording, which is another argument for not letting an affiliate URL be the thing that gets previewed.

Test it: paste the short link into a private message or an unpublished draft and read what the card says before you publish.

Automate the check in CI

Hand-checking every draft doesn't scale past a few posts a week. Because the redirector already knows which codes are affiliate links, the same links.js map can drive a pre-publish check over your drafts:

// scripts/check-disclosures.mjs
// Usage: node scripts/check-disclosures.mjs drafts/*.md
import { readFile } from "node:fs/promises";
import { links } from "../links.js";

const SHORT_LINK = /https?:\/\/sho\.rt\/([A-Za-z0-9_-]+)/g;
const DISCLOSURE = /(#ad\b|\bad:|\baffiliate link\b|\bpaid link\b|\bsponsored\b)/i;
const WINDOW = 140; // characters of context required before the link

let failed = false;

for (const file of process.argv.slice(2)) {
  const text = await readFile(file, "utf8");

  for (const match of text.matchAll(SHORT_LINK)) {
    const link = links.get(match[1]);
    if (!link?.affiliate) continue;

    const start = match.index ?? 0;
    const context = text.slice(Math.max(0, start - WINDOW), start);

    if (!DISCLOSURE.test(context)) {
      failed = true;
      const line = text.slice(0, start).split("\n").length;
      console.error(`${file}:${line} affiliate link without a nearby disclosure`);
    }
  }
}

process.exit(failed ? 1 : 0);

Wire it into the same pipeline that lints your markdown:

- name: Check affiliate disclosures
  run: node scripts/check-disclosures.mjs drafts/*.md

The window is deliberately crude. A regex can't judge whether a disclosure is clear and conspicuous, only whether one exists within a reasonable distance of the link. That's enough to catch the real failure mode, which is forgetting entirely.

Verify the redirect actually behaves

After deploying, check headers rather than the rendered page:

curl -sI https://sho.rt/spring-sale | grep -iE '^(HTTP/|location|x-robots-tag)'

For an affiliate code you want no Location header, a 200, and x-robots-tag: noindex. A 302 means the affiliate branch isn't being hit, usually because the affiliate flag is missing from the map.

Edge cases worth deciding in advance

Character limits. An affiliate URL with tracking parameters can eat most of a post. Budget the disclosure first (Ad: is four characters) and shorten what's left.
Threads. Repeat the disclosure in every post that carries a link, not just the first one.
Image-only posts. The disclosure belongs in the text of the post containing the image, not only in your profile.
Quote posts and reposts. Your disclosure doesn't travel with someone else's quote of your link. Assume it's lost and don't rely on it.
Multiple links. One clear disclosure at the top covering the whole post is normally fine; just make sure it isn't separated from the first link by a wall of text.

Should You A/B Test Your Call to Action or Your Landing Page First?

Yuto Tanaka — Tue, 27 Oct 2026 00:00:00 +0000

A campaign lands in your lap and the numbers are flat. The button says "Submit." The page is three paragraphs of feature copy above the fold. You have one experiment slot this sprint, one shared traffic budget, and two candidate changes that both look obviously wrong.

So which one do you ship first?

The useful answer is neither "test both" nor a coin flip. The two changes answer different questions, and one of them is usually wasted if you run it in the wrong order.

The two problems look identical in a dashboard

Both failures surface as the same line: campaign traffic arrives, signups don't happen. To separate them, split the funnel into two questions.

Does the page earn attention? Can a first-time visitor understand the offer within the first screen?
Does the ask earn commitment? Once the value is clear, is the action obvious, specific, and low-friction?

The first question is about the landing page. The second is about the call to action. A dashboard that only tracks sessions and signups cannot tell you which one broke.

A diagnostic table before you write any code

What the data shows	Likely cause	Where to start
Most sessions end within a few seconds; low scroll depth	The page does not match the promise in the ad	Landing page
Deep scroll, pricing or docs section viewed, few form starts	The ask is vague, buried, or costly	Call to action
Many form starts, few completions	Form friction	Neither. Fix the form
Low engagement and low action, traffic source unclear	Targeting or message mismatch upstream	Neither. Fix the campaign

That last row matters more than it looks. If the audience arriving from the campaign was never a fit, no amount of button rewording or hero-copy polishing will rescue the page. Fixing the targeting is cheaper than any experiment.

Why the order matters more than the individual change

A call to action is read in the context of the headline, the proof, the price, and the surrounding copy.

That produces two ordering rules.

Rule one: a button cannot fix a page that never establishes value. If visitors leave before they understand what they are being asked to do, a sharper label has nothing to attach to. You will measure noise and conclude that labels do not matter.

Rule two: do not optimize a component you are about to replace. If a page rewrite is already on the roadmap for this quarter, running a careful label experiment on the current page is a throwaway. The result will not transfer to the new layout, because the context that produced it no longer exists.

The second rule is the one teams break most often, because label experiments are fast to ship and feel productive.

Do the math before you commit to either

A small change usually produces a small effect, and a small effect demands a large sample. A page rewrite can plausibly shift behavior by several points; a button label change often moves it by a fraction of one.

A quick calculation, runnable in any Python environment, shows how steep that difference is:

import math

def sessions_needed(p_control, p_treatment, alpha=0.05, power=0.80):
    z_a = 1.959963985
    z_b = 0.8416212336
    p_bar = (p_control + p_treatment) / 2
    spread = (z_a * math.sqrt(2 * p_bar * (1 - p_bar))
              + z_b * math.sqrt(p_control * (1 - p_control) + p_treatment * (1 - p_treatment))) ** 2
    print(math.ceil(spread / (p_treatment - p_control) ** 2))

sessions_needed(0.04, 0.045)   # a 0.5-point lift on a 4% baseline
sessions_needed(0.04, 0.06)    # a 2-point lift on the same baseline

On a 4% baseline, detecting a 0.5-point improvement at 80% power takes roughly 25,000 sessions per arm. Detecting a 2-point improvement takes roughly 1,900. Same campaign, same page, a thirteen-fold difference in required traffic.

Two conclusions follow. First, if your campaign delivers a few thousand sessions a month, a micro-optimization of the button label is probably not measurable, no matter how good the label is. Second, the size of the expected effect should drive the choice of experiment far more than how easy the change is to ship.

A default order that holds up in practice

Verify the instrumentation. One exposure event per session, assignment logged server-side rather than inferred from a query parameter, internal traffic excluded, bots filtered. Every downstream conclusion inherits the quality of this step.
Check message match. Put the ad headline next to the page headline. If they describe different things, stop here.
If message match fails, run the landing page experiment first. Change the hero, the offer framing, or the proof: the elements that determine whether a visitor stays long enough to be asked anything.
If message match holds and engagement looks healthy, run the call-to-action experiment. Label, placement, and the one or two lines of supporting copy next to it.
Re-run the call-to-action experiment after any page rewrite. Treat the old result as historical, not as a default.

Step 4 is where a lot of teams want to start, and it is a legitimate starting point, but only when the diagnostic in the table above says the page is already doing its job.

Track what happens after the action, not just the action

A call to action that increases signups while filling the pipeline with people who never come back is a net loss. Before you run either experiment, decide on guardrail events and log them alongside the primary metric:

// One exposure event per session, emitted once and cached client-side
trackEvent("experiment_exposure", {
  experiment_id: "cta_copy_q3",
  arm: "specific-verb",
  campaign_id: "launch_aug",
});

// Downstream quality signals, tied to the same session
// activation_started, first_key_action, repeat_usage_7d

If the primary metric moves up and a guardrail moves down, that is a trade-off that needs a decision. Guardrails are especially important for landing page experiments, because a page that over-promises will inflate the action rate and damage downstream quality.

Do not change both at once

Running a page experiment and a call-to-action experiment simultaneously on the same traffic makes the result unreadable. You cannot tell whether the change came from the page, the ask, or the interaction between them.

If you genuinely need both answers and have the traffic to support it, use a factorial design: four arms, so every page version is paired with every call to action. The interaction term is often the most interesting number in the output, because it tells you whether a strong page makes the label irrelevant. The cost is roughly four times the traffic of a two-arm experiment.

For most campaigns, sequential experiments are the practical choice: page first, then the ask, with each experiment consuming a pre-committed block of traffic. Avoid switching between them mid-run based on how the numbers look.

Link hygiene when campaign traffic is split

If you are routing campaign traffic between page builds and call-to-action experiments, the link you publish becomes part of the workflow. Campaign copy already competes for space with a headline and a button, and long parameter-heavy URLs wrap badly in chat apps and social posts. A short link such as LinkBit keeps the destination compact and readable in the creative. That is a formatting convenience. Your experiment assignment should live in your own instrumentation, not in the link.

The short answer

Run the landing page experiment first when the funnel shows that visitors never engage, when message match is broken, or when a rewrite is already planned. Run the call to action first when the page is doing its job and the ask is the weak link, and only when your traffic is large enough to detect the smaller effect you are likely to see.

Before either, confirm what your instrumentation measures. Most experiment programs that stall are running careful changes on a funnel they cannot see.

Why Your Link A/B Test Gets Uneven Traffic, and How to Fix It

Yuto Tanaka — Mon, 19 Oct 2026 08:01:12 +0000

You set a redirect test to split 50/50. A day later the dashboard says 62/38. Before you call it a winner, check the plumbing. In link tests, uneven traffic is often an assignment or caching bug, not random variation.

This post covers the common causes and a server-side pattern that keeps the split honest.

Random assignment does not guarantee even observed traffic

Math.random() < 0.5 gives each request an equal chance of variant A. It does not guarantee that the first 100 requests split 50/50. With small samples, variance is normal. With thousands of exposures, a 60/40 split is a signal.

Two things to separate:

Assignment: which variant the system chose.
Exposure: which variant actually reached the user and was logged.

Most 'uneven traffic' bugs live in exposure or caching, not in the random function.

The usual suspects

1. Permanent redirects

A 301 tells browsers and CDNs to cache the redirect. The first variant can stick for every later request. Use 302 or 307 for tests, and set Cache-Control: no-store on the redirect response.

2. CDN or edge cache

If your redirect is cached at the edge, the first request decides the variant for everyone in that cache region. Make the redirect response uncacheable, or move assignment to the edge with a key that varies per user.

3. Assignment after the redirect

If you assign the variant on the destination page with JavaScript, you miss users who block JS, bots, prefetchers, and link previews. You also log exposure late. Assign before the redirect and log there.

4. Unstable assignment keys

A new cookie per request, a session ID that resets, or a hash of IP + user agent can reshuffle users. Mobile IPs change, UA strings change, and cookie blockers delete state. Use a first-party cookie with a generated ID, and fall back to a deterministic hash only when necessary.

5. Bots and prefetch

Slack, email scanners, and browsers prefetch links. They can hit both variants or hit one repeatedly. Filter known bots from analysis, and log user-agent plus a bot flag at exposure time.

6. Multiple entry points

If one campaign link uses the splitter and another points directly to variant B, your traffic is not a clean 50/50. Route every test link through the same splitter.

7. Race conditions

Parallel requests from the same user can assign twice before the cookie is written. This is rare, but it happens with prefetch plus navigation. A deterministic hash of the stable cookie ID prevents double assignment.

A server-side pattern that holds up

Use a stable anonymous ID, hash it with the test name, and map the hash to a bucket. Set the cookie if missing, redirect with 302, and disable caching.

const crypto = require('crypto');

function bucket(key, buckets = 2) {
  const hash = crypto.createHash('sha256').update(key).digest();
  return hash.readUInt32BE(0) % buckets;
}

app.get('/test/:testName', (req, res) => {
  const cookieName = `ab_${req.params.testName}`;
  let anonId = req.cookies[cookieName];

  if (!anonId) {
    anonId = crypto.randomUUID();
    res.cookie(cookieName, anonId, {
      httpOnly: true,
      sameSite: 'lax',
      maxAge: 1000 * 60 * 60 * 24 * 30
    });
  }

  const variant = bucket(`${req.params.testName}:${anonId}`, 2);
  const target = variant === 0
    ? 'https://example.com/landing-a'
    : 'https://example.com/landing-b';

  res.set('Cache-Control', 'no-store');
  logExposure({ test: req.params.testName, variant, anonId, ua: req.get('user-agent') });
  res.redirect(302, target);
});

Notes:

The cookie name includes the test name so different tests do not collide.
no-store is not optional. Without it, a CDN can freeze the split.
Log exposure before the redirect. Destination-page analytics cannot see users who never load the page.
If you need to run this at the edge, use the same hash and set a first-party cookie or use an existing stable ID.

What about fairness? SHA-256 modulo 2 is close enough for practical tests. For more than two variants, use modulo N. For very large tests, consider a uniform hash range and map to buckets to avoid modulo bias, though the bias is negligible for small N.

Check for sample ratio mismatch

Sample ratio mismatch (SRM) means the observed split differs from the planned split. A quick chi-square check catches broken assignment early.

function srmWarning(counts, expectedRatio = [0.5, 0.5]) {
  const total = counts.reduce((a, b) => a + b, 0);
  let chi = 0;

  for (let i = 0; i < counts.length; i++) {
    const expected = total * expectedRatio[i];
    chi += Math.pow(counts[i] - expected, 2) / expected;
  }

  // 1 degree of freedom, p < 0.001
  return chi > 10.828;
}

const counts = [620, 380];
if (srmWarning(counts)) {
  console.warn('Sample ratio mismatch: check redirect caching, bot traffic, and assignment keys.');
}

If you see SRM, do not 'fix' it by rerunning the test and stopping when the split looks even. Fix the cause, then start a fresh test.

Practical checklist

Use 302 or 307, never 301, for test redirects.
Send Cache-Control: no-store on the redirect response.
Assign from a stable first-party ID, not a fresh random value per request.
Log exposure at redirect time with variant, test name, timestamp, and a bot flag.
Route every campaign link through one splitter.
Exclude known bots and internal traffic before analysis.
Monitor SRM daily; stop and debug if it appears.

When you share test links

A/B tests create more URLs: variant A, variant B, docs, Slack messages. Manual edits cause mistakes. A short link can keep the shared URL stable while the splitter handles the variant choice. LinkBit is a link shortener you can use for that kind of sharing: LinkBit.

The main fix is still server-side assignment and cache-safe redirects. Short links just make distribution tidier.

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.