Print intent event
A print intent event records that a user printed (or opened the print dialog for) a page, using the browser beforeprint and afterprint events. As a UX signal it suggests reference-grade content people want offline — recipes, tickets, instructions. It is not a native GA4 event; you listen and send a custom event. It carries only the page or section context, never anything identifying about the visitor.
How it is detected
Browsers fire a beforeprint event when printing is requested and afterprint when the dialog closes (MDN: Window beforeprint_event). You attach listeners and emit a custom analytics event — typically on beforeprint — with the page path or section as a parameter. matchMedia('print') is an alternative detection path for the same intent.
Why the signal is useful
Printing implies a user wants the content away from the screen: directions, a confirmation, a reference table. Pages with notable print activity are good candidates for a dedicated print stylesheet, a 'download PDF' option, or a layout that drops navigation chrome when printed. The signal is coarse and anonymous, which is exactly what you want for a content-design cue.
- Listen on beforeprint/afterprint or matchMedia('print')
- Emit a custom event with page context only
- Use it to drive print-friendly layouts, not profiling
How it appears in analytics and logs
Print signals concentrated on certain pages indicate content used as a physical reference — a cue to provide a clean print stylesheet or downloadable version.
Diagnostic use case
Identify pages users print for offline use by emitting a custom event on beforeprint, so you can offer print-friendly layouts or PDFs for those pages.
What WebmasterID can help detect
WebmasterID can record a print signal as a labelled custom event keyed to the page, helping you find print-heavy content without profiling visitors.
Common mistakes
- Trying to capture what was printed rather than that it was.
- Firing repeatedly if the dialog re-opens.
- Assuming every print equals a conversion.
Privacy and accuracy notes
A print event needs only page context. It reveals nothing identifying and you should keep it that way — no user identity, no document contents in the event.
Related pages
- Custom events: tracking what matters to you
Custom events capture meaningful actions a pageview cannot — a CTA click, a signup, a video play, a form submit. The value is in a consistent naming taxonomy and well-chosen properties. The risk is putting personal data into event names or properties, which turns analytics into surveillance. This page covers both.
- Copy interaction event
A copy interaction event records that a user copied text from the page, using the browser copy event. As a UX signal it can hint at which content people find worth saving — code snippets, addresses, prices — without telling you who copied. It is not a native GA4 event; you listen for copy and send a custom event. Crucially you log that a copy happened and where, never the copied text itself.
- Event parameters: adding context safely
Event parameters are the key-value details attached to an event: which button, which product, which step. They are what turns a bare event name into something analysable. The craft is choosing a small, stable set of parameters with consistent names and values — and the discipline is keeping every one of them free of personal data, because parameters are stored and widely visible in tooling.
- Events reference (docs)
Record print intent as a non-identifying custom event.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.