What variable data printing changes
An ordinary print run makes the same sheet a thousand times. Variable data printing makes a thousand different sheets in one pass, each one pulling a name, a number, a code or an image from a data file. The press does not stop between pieces, so the run costs closer to a standard digital job than to a thousand separate orders.
Most people meet it first as personalised direct mail, but the mechanism is the same whether you are changing a first name on a letter or a serial number on a ticket. What varies is how much of the layout moves. Swapping one line of text is straightforward. Changing a photograph, a language and a block of body copy per recipient is a different job, and worth flagging when you ask for a quote.
Where it earns its keep
- Event tickets and passes with sequential numbers or unique QR codes
- Vouchers and promotional codes that need to be single-use
- Membership and loyalty cards carrying a name and an account number
- Name badges printed in one run instead of handwritten on the morning
- Direct mail where the offer changes by postcode or customer segment
- Certificates, warranty cards and asset labels with an ID on each piece
The common thread is that each piece has to be traceable or personal. If nothing on the sheet changes, you do not need variable data and should not pay for the setup.
Preparing the data file
Almost every delay on a variable job comes from the spreadsheet, not the artwork. The press will print exactly what the file says, including the blank cells and the stray spaces.
One row per printed piece
The file needs a single header row and then one row for every item you want printed. Merged cells, subtotals, colour coding and a second table further down the sheet all have to go. Supply it as CSV or a plain single-sheet spreadsheet with no formulas left live, because a formula that reads from a deleted column arrives as an error string and prints that way.
Clean the columns before you send them
Names imported from a CRM carry the mess of wherever they came from: trailing spaces, all-caps entries, a first and last name jammed into one field, a placeholder like "Customer" where the data was missing. Decide how each of those should look on the printed piece and fix it in the sheet. Correcting 40 rows in a spreadsheet takes minutes, and correcting them after 2000 pieces are cut takes a reprint.
Check the longest value, not the first
Layouts get approved against the first row, which is usually a short name. Sort each column by length and look at the longest entry. A field sized for "Lee Wei" will break when it reaches a fourteen-character double-barrelled surname or a company name with a legal suffix. Either the text overflows the box or the software shrinks it to a size nobody can read.
Decide what an empty field does
Blank cells are normal in real data. What matters is the rule: does the piece print without that line, does it fall back to a generic greeting, or should the row be pulled from the run entirely? Say so when you send the file. Without a rule, the default is a gap on the page where the missing value should be, along with the punctuation around it stranded on its own.
What the artwork needs
The layout is built as a normal print file with placeholders where the data lands. Two details make the difference between a clean run and a set of proofs going back and forth.
First, give every variable field room to breathe. A text box sized exactly to the sample value has no tolerance, and the longest entries in your file will decide how the run looks. Leave space, set a sensible minimum type size, and agree in advance whether long values wrap to a second line or reduce in size.
Second, keep the variable elements away from the trim and the fold. A serial number 2mm from the edge will sit at different distances from the cut across a run, because trimming tolerance is a range rather than a single value. Barcodes and QR codes need their quiet margin preserved as well, and they should be generated from the data rather than pasted in as images. The rest of the file follows the usual rules, which we set out in exporting a print-ready PDF.
What it costs against a standard run
Variable data work is priced in two parts: a one-off setup for building and testing the merge, and then the normal per-piece cost of the printing itself. The setup is where the variation sits. A single text field merged from a clean CSV is a short job. Multiple fields, conditional rules, generated barcodes and images that change per record all add time, and a data file that needs cleaning adds more.
The per-piece cost is close to standard digital printing, which is what makes the technique worth using at all. There is no plate to change and no press stoppage between items, so a run of 500 personalised postcards prints at roughly the speed of 500 identical ones. Offset printing cannot do this, which is why very large runs are sometimes printed blank on offset and then overprinted digitally with the variable elements in a second pass.
Two practical consequences follow. Small variable runs are viable in a way they are not with offset, so a hundred numbered certificates is a reasonable order rather than an awkward one. And the saving from a bigger run is smaller here than on a static job, because the per-piece cost is doing most of the work in the total. If you are weighing quantities, ask for prices at two or three break points rather than assuming the usual curve applies.
Ordering a variable run online
We handle variable data work on the same digital equipment as standard short-run printing, so the turnaround is similar once the data is clean. To get a firm price rather than an estimate, send these together:
- The data file, or a sample of 20 rows that includes your longest and messiest entries
- The artwork with the variable fields marked, and a note on which column feeds which field
- The rule for blank fields and for values that run long
- Quantity, stock and finish, and whether pieces need to stay in data order after cutting
- Any numbering that must be sequential and unbroken, since that changes how the job is imposed
We proof a variable job differently from a static one. Rather than one sample, you get a spread showing the first rows, the last rows and the extremes we found in your data, so the layout is checked against the values most likely to break it. On runs above a few hundred pieces it is worth ordering a physical sample first, for the reasons covered in ordering a print sample before a big run.
Data files stay on our system only for the job they were sent for, and we delete them on request once the run has been delivered. If you want to talk through whether your list is in a usable shape before you commit, the digital printing page lists what the presses handle, and you can send us the file for a look. A ten-minute check of the spreadsheet is the cheapest part of the whole job.
