Event signal:page.visited| Destination:Intercom| Use case:Page Visit Triggers for Intercom| Typical setup:~15 minutes
Workflow outcome
The workflow starts with page.visited from your product and ends with an Intercom contact carrying the tag that represents the high-intent behavior you care about.
That turns a repeated product behavior into a message-ready signal while the user still has intent, instead of leaving the page view trapped in analytics where nobody can act on it fast enough.
Why teams care
PLG teams and onboarding-heavy products see high-intent behavior long before a form submission or demo request arrives. Repeated visits to pricing, API docs, or billing pages are often the real signal.
The timing matters as much as the behavior. A tutorial, support prompt, or internal escalation only helps if it shows up while the user is still exploring the page that created the signal.
Once teams care about repeated-visit thresholds, tag naming, and proof that the message-ready state actually landed, the simple version of page tracking becomes operational work.
What it depends on
These pages stay focused on the workflow outcome, but the setup still needs the right workspace, destination connection, and event path underneath.
You need a workspace and publishable key so your product can emit page.visited.
Authorize Intercom in Meshes and confirm the tags you plan to use for high-intent behaviors.
Read moreYour app should emit page.visited with identity, page context, and visit_count when the behavior becomes meaningful.
Decide which resource or page identifiers represent pricing intent, API docs exploration, billing intent, or another behavioral bucket worth tagging.
The source event
For Intercom, the event should explain who showed intent, which page created it, and why this page visit is different from ordinary browsing. That is where visit_count and page context matter.
Event payload
page.visited{
"user_id": "usr_8801",
"email": "sam@pipelineops.io",
"page_url": "/pricing",
"page_title": "Pricing",
"visit_count": 3,
"plan": "growth",
"visited_at": "2026-03-21T16:02:00Z"
}What matters most
Lets Intercom match the signal to the right contact record.
page_url
Shows which product or commercial surface created the intent signal.
page_title
Keeps the behavioral context readable in delivery logs and downstream review.
visit_count
Distinguishes routine browsing from repeated behavior that deserves a real-time response.
plan
Adds commercial context so the follow-up can reflect what the user appears interested in.
Field mapping view
| Event field | Destination target | Why it matters |
|---|---|---|
| Intercom contact lookup | Ensures the tag lands on the right user instead of becoming an orphaned signal. | |
| page_url | Tag or rule context | Separates pricing intent from API docs research or billing intent. |
| page_title | Readable delivery context | Makes it easier to audit why the tag was applied when reviewing event history later. |
| visit_count | High-intent threshold context | Explains why this visit should trigger an Intercom-ready state instead of being ignored. |
| plan | Tag naming or downstream segmentation | Lets the Intercom side distinguish one commercial interest path from another. |
The destination connection
In your Meshes workspace, connect Intercom and decide which existing tags should represent pricing intent, API docs research, or billing-help behavior. A short, explicit set of tags is easier to map in Meshes rules and easier for your team to trust later.
page.visited events.Where Meshes matters
Most teams do not need another destination. They need the destination to stay in sync without embedding its delivery quirks, retries, and mapping logic into the product code path.
In Meshes, bind page.visited to an Intercom Add Tag rule for the page resource that represents the intent you care about. Emit the event when your product sees the threshold crossing that matters, then let Meshes handle the Intercom handoff, retries, and delivery visibility.
A sample event
This is the part teams like: the source event stays readable and product-shaped while Meshes owns the destination-facing complexity.
TypeScript example
import MeshesEventsClient from '@mesheshq/events';
const events = new MeshesEventsClient(process.env.WORKSPACE_PUBLISHABLE_KEY!);
await events.emit({
event: 'page.visited',
resource: 'page',
resource_id: 'pricing',
payload: {
user_id: 'usr_8801',
email: 'sam@pipelineops.io',
page_url: '/pricing',
page_title: 'Pricing',
visit_count: 3,
plan: 'growth',
visited_at: '2026-03-21T16:02:00Z',
},
});Destination outcome
Use Send Test Event in Meshes or emit page.visited after the repeat-visit threshold is crossed. The Intercom contact should receive the high-intent tag, and any in-app message, support flow, or tutorial watching that tag can react immediately on the Intercom side.
Operational visibility
The difference between a nice demo and a usable product workflow is whether you can see what happened when the destination is slow, misconfigured, or unavailable.
In Meshes
page.visited event appears in Meshes and the Intercom rule is matched.Why teams buy Meshes
What's next
Use Case
See the broader pattern for routing page-visits into Intercom, Slack, and internal systems.
Open linkIntegration
Review the Intercom connection flow, tag actions, and event result details.
Open linkDocs
Use the Meshes events API or SDK to emit page.visited from your product.
Compare
Compare real-time intent routing with maintaining custom page-tracking workers and retry logic yourself.
Open linkGuide
See a companion behavior-driven guide where onboarding moves from real progress instead of timer-based drips.
Open linkGuide
Project repeated page intent into HubSpot properties and sales follow-up instead of Intercom tags.
Open linkpage.visited when the behavior becomes meaningful and let Meshes handle the tag handoff, retries, and delivery visibility that real-time intent workflows need.