QR codes on direct mail, one code per mailing batch or segment
This is a scan-attribution layer, not a mail merge tool
OpenQR doesn't personalise the letter, manage the mailing list, or handle postage. What it does is give each list, batch or segment its own trackable code, generated in bulk from that list's own labels, to drop into whatever mail merge or fulfilment process is already running.
Split the destination and its UTM tag along however the list was actually cut, lapsed versus active, high value versus standard, region, a specific data pull date, rather than inventing a split after the mailing has gone out. Decide the segments before the merge so each code and its segment stay locked together for the life of that mailing.
A code per segment, this page's scope, tells you which list responded. A code per individual recipient tells you which person responded, and that's a mail merge and print-personalisation problem this page doesn't solve: it needs a unique code placed on the correct letter at merge time. The bulk generator can technically produce hundreds of distinct codes from a CSV, one row per recipient, but getting the right code image onto the right letter is print-shop and mail-merge tooling, not something generating the codes alone guarantees. For most direct mail, segment-level attribution answers the real question, which list worked, without that added complexity.
| Segment | utm_content | Label | Typical volume |
|---|---|---|---|
| Lapsed customers (12mo+) | segment-lapsed | Mail - Lapsed | Thousands |
| Active customers | segment-active | Mail - Active | Thousands |
| VIP or high value | segment-vip | Mail - VIP | Low hundreds |
| Purchased prospect list | segment-prospect | Mail - Prospect | Thousands |
A landing page matched to the segment is stronger where you can manage it, a lapsed-customer offer reads differently to a VIP one, but even a single shared landing page still benefits from the UTM split, because the value is in knowing which segment scanned, not necessarily giving each one a bespoke page. Keep utm_campaign identical across segments and vary only utm_content.
Direct mail has the slowest, longest tail of anything on this site
A leaflet gets read the day it lands; direct mail sits on a kitchen counter for weeks. Don't compare segments after three days. Give a send at least two to three weeks before drawing conclusions, and look at the daily series (or the full history, on Pro) for a long, low tail of scans rather than expecting a spike.
Running a segmented direct mail send
Cut the list into segments before the merge
Based on a real difference, recency, value, region, not an arbitrary split.
Tag one destination URL per segment
A shared utm_campaign, a segment-specific utm_content.
Generate one dynamic code per segment
In the bulk generator, labelled with the segment's name.
Hand the code image to whoever runs the merge
One image per segment's print run.
Group the segment codes in one folder
So the send stays together in the dashboard.
Wait two to three weeks, then compare per thousand mailed
Segment sizes rarely match, so normalise before comparing.
Many direct mail recipients respond by phone, by visiting in person, or by typing a web address rather than scanning, especially older or less mobile-first segments, so a segment with few scans is not automatically a segment that didn't respond, it may simply have responded a different way. If a segment matters enough to judge properly, ask about response channel in your call-handling or in-store process too, rather than relying on scan data alone for that audience.