Email tools in the browser

1. Two bridges, one job, different trade-offs

MousePlayer can reach your email platform two ways, and which one is right depends on something simple: does the tool run on your page?

	This bridge (browser)	Lifecycle (server-side)
Runs	in the visitor's browser	on our server
Needs credentials	no	yes - an API key
Works when	the tool's script is on the page	always, script or not
Fires	as soon as the session is identified	the same moment
Tools	Klaviyo, Braze, Iterable, Ortto, Emarsys, Bloomreach and more	ActiveCampaign, Mailchimp, Iterable, Klaviyo, Braze, Customer.io, Brevo

If the tool is on your page anyway, this bridge is the cheaper choice: nothing to configure, nothing to keep secret, nothing that can expire.

2. What each tool wants

The category hides a lot of variety. Two of them are worth knowing before you switch the bridge on.

Emarsys does nothing until you tell it to go

Its command queue collects everything and executes none of it until a ['go'] arrives. A bridge that pushes attributes and stops looks, from the outside, exactly like a bridge that is not working - the values sit in the queue forever. We send the go.

Ortto needs the activity to exist first

The activity has to be created in your Ortto account and released for client-side use. Without both, the call answers 404 - and a 404 from a tool that is clearly loaded reads like a bug on our side rather than a setting on yours.

Klaviyo and Braze read identity from their own cookie

Which means they work for a visitor who was identified in an earlier session, not only in this one.

3. Where the value lands

As a profile attribute or a custom property called mouseplayer_session_url, depending on what the tool calls that concept. From there it is usable in exactly the places you would want it:

• In a segment. "Everyone who abandoned checkout" is a segment you already have; adding the replay link makes it a queue of things to watch.
• In an email. Not to the customer - to your own team, in an internal alert.
• In a lifecycle flow. The support handover step can carry the recording, so whoever picks it up starts with the evidence.

4. When to use the server-side one instead

Three cases, and they are worth checking before you choose:

• The email tool is not embedded on your site. Many are not - a platform used only for campaigns has no script on your pages, and a browser bridge has nothing to write into.
• You need it to be reliable rather than best-effort. A browser bridge depends on the visitor's page staying open long enough; the server-side one runs from a queue with retries.
• You want it to work with an ad blocker in the way. A blocked marketing script cannot receive anything. Our own recording is unaffected, but the bridge into a blocked tool is not.

The two can also run together. They do not conflict - the browser one writes an attribute, the server one sends an event, and the tool treats them as different things.