Query string filter
The Query string filter matches visitors by a URL parameter they arrived with, such as ref=producthunt or gclid. Personizely remembers the parameters it sees in each visitor's URLs, so the visitor keeps matching on later pages and visits, even when the parameter is no longer in the address bar.
Available on: all platforms.
How it's evaluated
The filter doesn't read the URL of the page the visitor is on. It reads the value remembered for the visitor under that parameter name.
What's remembered
On every full page load, Personizely saves each parameter in the page's URL for the visitor, as decoded text (?q=summer%20sale and ?q=summer+sale are both saved as summer sale). Two kinds of parameters are handled differently:
- The five UTM parameters (utm_source, utm_medium, utm_campaign, utm_term, utm_content) are saved as the visitor's UTM values. Using one of these names in this filter checks the same value as the UTM parameters filter.
- Parameters whose name starts with ply are reserved for Personizely (for example ply_preview_campaign) and are never saved.
The values are saved before targeting runs, so the landing page itself already sees them.
When it's overwritten
Each parameter is overwritten on its own:
- A parameter that's in the URL replaces the saved value for that name, including with an empty value (?ref= saves an empty value). If the same parameter appears twice in one URL, the last one is saved.
- A parameter that's not in the URL keeps its saved value. Nothing is cleared: not on pages without parameters, not on a new visit, and not after a period of time.
For example, a visitor lands on /?ref=producthunt, browses, and a week later returns through /?ref=newsletter&coupon=SPRING. From then on, ref is newsletter and coupon is SPRING. If they come back again with no parameters, both values stay.
The values start over only when Personizely sees the person as a new visitor: after they clear cookies and site data, in a private window, or on another browser or device. Saved parameters stay in the visitor's browser storage.
Targeting the current URL instead
- Widgets: use the Query string rule. It reads only the current page's URL, so a widget shown for ?ref=producthunt doesn't follow the visitor to other pages.
- Campaigns: set the campaign's page to Multiple pages with Include query on, and a rule such as Include pages containing ref=producthunt, or a RegExp such as [?&]ref=producthunt(&|$).
Options
The filter reads: Query parameter name operator value.
Option | What it does | Values / default |
|---|---|---|
Query | The parameter name, exactly as in the URL | Text, for example ref |
Operator | How the saved value is compared | contains (default), is, is not, does not contain, is empty, is not empty |
Value | The text to compare with | Required, except for is empty / is not empty |
Behavior details
- Case-sensitive names and values. Ref and ref are different parameters; ProductHunt and producthunt are different values.
- Missing equals empty. A parameter the visitor has never had counts as empty, so is empty, is not and does not contain match visitors who never arrived with it. To require that the visitor arrived with the parameter at all, use is not empty.
- Click IDs work. "Query gclid is not empty" matches visitors who ever arrived through a Google Ads click, and keeps matching afterwards.
- Single-page storefronts. Only full page loads update the saved values. Parameters added to the URL by an in-page navigation are picked up on the next full page load.
- Dynamic text uses the same values. {query.ref} in dynamic text shows the saved value, not only the current URL's.
Examples
- Launch-day visitors: Query ref is producthunt, to keep a launch discount visible during their whole visit and when they return.
- Google Ads visitors: Query gclid is not empty, to test a landing experience for paid search traffic.
- Affiliate traffic: Query aff is not empty, to hide your own discount popup from visitors who already have an affiliate code.