Someone clicks your newsletter link, browses a few pages on your site, then clicks through to an external booking site. The campaign tags are no longer in the page URL. How will the booking site know the visitor came from your newsletter?

UTM Keeper saves selected campaign tags in the visitor’s browser. When they click an external link you choose, it adds those tags to the destination URL. This helps the destination attribute bookings or purchases to your campaigns. It does not keep the tags visible in your site’s page URLs or provide analytics itself.

Example: newsletter to booking

A visitor lands on your site with ?utm_source=newsletter&utm_campaign=spring. After browsing pages without those tags in their URLs, they click your configured link to https://bookings.example.com/book. UTM Keeper adds utm_source=newsletter&utm_campaign=spring to the booking URL, so the booking site can identify the campaign.

Other use cases

An ad brings someone to your site; they later follow your selected link to an external checkout.
A social campaign brings someone to your site; they later follow your selected link to an external registration page.

How it works

UTM Keeper is disabled by default. Once an administrator enables it, the plugin stores selected campaign parameters in one expiring localStorage record for this site’s browser origin. No plugin account, external service, cookies, or runtime packages are required. The plugin does not create server-side visitor records or send attribution to a plugin service; clicking a targeted link sends the resulting URL to that destination through normal browser navigation.

The five standard UTM keys (utm_source, utm_medium, utm_campaign, utm_term, utm_content) are selected by default. gclid and fbclid are optional. Unknown keys, empty/whitespace-only values, and values longer than 256 UTF-16 code units are ignored. A visit with at least one valid selected key replaces the whole previous set (last touch); a visit without valid selected keys leaves it unchanged without extending expiry. Retention is 30 days by default, configurable from 1 to 90 days from capture. Invalid or expired records are removed when checked. Unavailable browser storage means attribution cannot be captured or forwarded; there is no cookie or server fallback.

Only external HTTPS links to an exact configured DNS hostname or links marked with the CSS class utm-keeper qualify. Both require no embedded credentials and no download attribute. Forwarding happens on ordinary or middle click, including for links inserted after page load, not by rewriting all links on page load. Existing destination query keys (even empty ones) take precedence; the destination path, existing query and fragment remain intact. Internal links, HTTP links, invalid URLs, and other unmarked/unconfigured links are left unchanged. No hostname is configured by default; marking a link is a separate opt-in.

Privacy and limitations

Campaign parameters can contain personal data. Forwarded URLs may be logged by destination servers and other intermediaries. Site owners are responsible for their own privacy notices, consent requirements, and destination practices. Enabling this plugin is not a consent mechanism and does not guarantee compliance. The plugin does not provide analytics, form-field population, consent management, or automatic forwarding to all outbound links.

For testing or to start fresh, use the “Clear attribution in this browser” button under Settings > UTM Keeper. It removes only this plugin’s localStorage record for the current browser profile and the admin page’s origin; it does not change saved settings, unrelated site data, or other visitors’ browsers. The button works even when the plugin is disabled, and reports if browser storage is unavailable. If the public site uses a different protocol, hostname, or port from the admin page, its storage is separate and this button cannot clear it. On that public site’s origin, you can instead run localStorage.removeItem('utmkeeperflow_attribution') in the browser console. Visiting a campaign URL again after reset can capture fresh attribution.

Automated JavaScript and PHP shim checks cover the described behavior and settings contract. Local integration was exercised on WordPress 7.1.2 with PHP 8.2.29; the “Tested up to” header reflects only the locally verified WordPress 7.1 line. Compatibility with other WordPress/PHP versions is not established by this single environment.