How To Trigger An Automation From A Page View

A page-view trigger starts an automation when someone visits a specified page or group of pages on your website. It is commonly used for product education, trial activation, renewal support and relevant follow-up after a known subscriber has shown interest.

The important qualification is known subscriber. A web analytics platform may record an anonymous browser visit, but an email platform cannot responsibly send an email until it can associate that activity with a person and confirm that the person is eligible for that message. Treat a page view as behavioural context, rather than automatic permission to contact somebody.

A sound implementation has four parts: capture the visit, connect it to the right person, decide whether the visit is meaningful enough to begin a journey, and apply eligibility and pressure controls before a message is sent.

Start with the outcome, not the URL

“Visited the pricing page” is a convenient trigger name, but it is not a strategy. First decide what a visit should mean and what useful help should follow from it.

For example, a person using a software trial who reads a guide to importing data may benefit from a short, practical setup email. A customer viewing a service-status page may need no marketing email at all. Someone looking at a careers page should not be enrolled in a sales sequence simply because the page sits on the same domain.

The strongest page-view automations usually support an existing customer or subscriber journey:

• A trial user views an integration guide but has not completed the related setup task.
• A subscriber returns to a webinar page after registration and can be sent joining details or useful preparation material.
• A customer views documentation for a feature included in their plan, then receives help using it.
• A consented retail subscriber views a product category several times but has not purchased from it recently.

In each case, the URL alone is insufficient. The automation needs other information: account state, subscription status, recent purchases or actions, prior messages, and the purpose for which the email address was collected.

Understand what a page view actually records

A page view is an event saying that a browser loaded a page, or that an application registered a route change. Depending on the implementation, it may contain a URL, page title, referrer, time, campaign parameters and browser details. It does not necessarily prove that a person read the page, understood it or intended to buy.

That distinction matters. A page can be opened accidentally, preloaded by a browser, visited by an automated scanner or revisited in several tabs. If a single load instantly sends a promotional email, the automation can easily feel intrusive and generate needless sending volume.

Use a canonical definition of the page or content area you mean to track. Strip technical URL parameters that do not change meaning, such as session identifiers and most campaign parameters. Decide whether language, region and trailing-slash variants represent the same page. If the page is part of a logged-in product, record a meaningful route or screen name rather than relying on a changing full URL.

For a single-page application, a JavaScript snippet loading once does not automatically mean that every in-app navigation is captured. Your development team may need to send a page-view event when the route changes. Conversely, check that the implementation does not send two events for one load: one from automatic tracking and one from a custom call. Customer.io, for example, explicitly warns that adding an extra page call alongside its default JavaScript page call can create duplicate page-view events. Customer.io’s JavaScript tracking documentation explains the behaviour and the need to handle URL parameters deliberately.

Make the visit attributable before using it for email

There are three broad identity states:

1. Anonymous visitor: the browser has visited a page, but you do not know who the person is.
2. Recognised visitor: the browser has a persistent identifier that your systems associate with a profile, usually after a previous form submission, email click or account activity.
3. Authenticated user: the person has signed in, so the product can associate the event with an account or contact more reliably.

Only the latter two states can normally support an immediate email automation, and even then the profile must be subscribed or otherwise eligible for the proposed message. A page view should never be used to turn an anonymous browser visit into a reason to email an address obtained elsewhere.

Where identification happens after anonymous activity, establish the rules for joining that history to the contact record. Some platforms can associate earlier anonymous events after a person identifies themselves; Customer.io describes this association for anonymous web events. Its event documentation also distinguishes ordinary page calls from custom tracked events. Whether you use that capability is a design decision: it should match the explanation in your privacy information and the choices the visitor has made.

Keep identity handling conservative on shared or public devices. A family computer, a library machine or a shared workplace browser can otherwise cause one person’s browsing activity to influence messages sent to another person’s inbox. For sensitive categories, avoid page-level behavioural targeting altogether unless the need and safeguards are clear.

Choose between a page-view condition and a custom intent event

Most automation systems offer one of two patterns.

Use a page-view condition when the visit itself is enough

Build a segment such as “has visited /plans/enterprise in the past seven days” and start an automation when a person joins it. This works well when you only need a broad, one-off qualification rule. It is usually easier to configure because the existing web tracker already records page views.

There is a trade-off: segment entry is a change in membership, not necessarily a new event every time the page is viewed. A person may have to leave the segment before they can qualify again. Platform behaviour varies. In Customer.io, for example, page events cannot directly start an automation; you can use a segment based on page views, or send a separate custom event if every qualifying view needs to start a journey. Customer.io’s guidance on triggering automations from page views sets out both options.

Use a custom event when a specific action has taken place

A custom event is usually the better choice where the business meaning is more precise than “a page loaded”. Instead of triggering on page_viewed, send an event such as integration_setup_guide_viewed, pricing_calculator_completed or renewal_options_viewed.

Give the event only the properties the workflow needs, for example:

event: renewal_options_viewed
properties:
  plan: professional
  renewal_date: 2026-11-30
  authenticated: true
  content_version: 3

Do not put an email address, full search query, form answers or other unnecessary personal details into event names or URL parameters. A focused event schema makes the workflow easier to audit and prevents sensitive data travelling into systems that do not need it.

Use an event trigger if the automation needs event-specific data, needs to distinguish a genuine in-product action from a simple web load, or should be eligible to run again under tightly controlled circumstances. HubSpot makes a similar distinction between filter-based and event-based enrolment: event triggers can be configured to enrol on each occurrence, while filters normally enrol when a record first meets the criteria. HubSpot’s workflow trigger documentation is a useful reminder to check re-enrolment behaviour before publishing.

Build the trigger as a decision, not a single rule

Once the event is arriving, create the automation in layers. The trigger begins the evaluation; it should not be the only condition.

A delay is often useful, but it should have a reason. Waiting 30 to 90 minutes can allow a person to finish their research or complete the action without being interrupted. A much longer wait may suit a considered purchase, while a product-onboarding message may need to arrive on the same day. During the delay, re-check the exclusion conditions: the person may purchase, complete setup, unsubscribe or receive a more important operational message.

For a simple example, a SaaS business might use this logic:

1. An identified trial user views the import documentation twice in seven days.
2. The workflow confirms that they have not completed an import and are eligible for onboarding email.
3. It waits two hours.
4. It checks the completion event again. If the import is still incomplete and the contact has not reached the message-frequency limit, it sends one help email.
5. The journey ends if the user imports data, converts, opts out or reaches its expiry date.

This is preferable to a generic “we saw you looking” message. The email can say what it is for: offer a short import guide, a troubleshooting resource or a route to support. Avoid wording that is more specific about a person’s browsing than necessary, particularly where the content could reveal something sensitive.

Respect consent, preferences and the purpose of the message

In the UK, tracking technologies used for analytics or behavioural tracking will often need consent. The Information Commissioner’s Office explains that consent is generally required for non-essential cookies and similar technologies, and that people must receive clear information about their purpose. The ICO’s guidance on storage and access technologies covers cookies, pixels, fingerprinting and related techniques.

That consent question is separate from whether you can send the email. For marketing emails to individual subscribers, PECR generally requires specific consent unless a limited soft opt-in applies. Each marketing email also needs a simple way to opt out. The ICO’s electronic mail marketing guidance explains the distinction and the requirements for the soft opt-in.

In practical terms, retain separate fields for tracking choices, email subscription status and product/service communications. Do not assume acceptance of website tracking means acceptance of marketing email, or that a newsletter opt-in permits every type of behavioural profiling. The exact design should be reviewed against your audience, jurisdiction and data flows.

Prevent one visit becoming several messages

Page-based automations often collide with one another. A person may visit a pricing page, a case-study page and a webinar page during the same research session. If each page has its own workflow, three otherwise reasonable automations can become an unwelcome cluster of messages.

Set an explicit contact-pressure policy across campaigns and journeys. Decide which messages take priority, such as security notices, transactional communications, trial onboarding and promotional follow-up. Suppress lower-priority workflows when a person is already in a relevant journey, and cap the number of marketing messages permitted over a defined period.

Also separate delivery from engagement assumptions. A message being delivered does not mean it was wanted, seen or useful. Monitor unsubscribe rates, spam complaints, hard bounces, workflow exits, conversion completion and the distribution of messages per contact. If the automation produces a sudden volume increase, watch sender reputation and inbox-placement indicators as well as campaign metrics.

This is where deliverability work can become directly relevant. If a page-trigger programme expands materially, a deliverability review can assess whether authentication, suppression handling, audience quality, contact-pressure rules and provider-level sending patterns support the new volume. Email Foundry’s managed work is intended for permission-based marketing and lifecycle senders; it is not a route to use web behaviour for unsolicited prospecting.

Test the entire path before switching it on

Do not test only whether the event appears in an activity log. Use controlled test profiles to follow the whole path from browser to inbox.

• Visit the qualifying page once, then several times, and confirm the expected count and event properties.
• Test logged-out, recognised and signed-in states separately.
• Accept, reject and withdraw tracking choices, then confirm that tags and downstream events behave as designed.
• Check URL variants, redirects, app-route changes and mobile journeys.
• Confirm that purchase, activation, support escalation, unsubscribe and suppression records stop or divert the journey.
• Trigger two competing journeys to make sure priority and frequency rules work.
• Review the rendered email, unsubscribe route, sender identity and reply handling in a real mailbox.

Where Google Tag Manager is used, consent configuration needs to be available before relevant tags fire, rather than added later through a custom HTML tag. Google’s data-layer guidance explains why consent updates and event sequencing matter. Keep a simple implementation record showing the event name, triggering pages, properties, identity rule, consent dependency, exclusions, re-entry rule, message owner and review date.

A page view is most valuable when it helps you provide timely, expected assistance to someone with an existing relationship with your organisation. Use it sparingly, define the behaviour precisely, and make the workflow easy to stop when the person has already done what they came to do.