Why server-side cookies?
Browsers like Safari and Firefox shorten the lifetime of cookies set in the browser. This means returning visitors can be forgotten unnecessarily. When cookies are instead set by your own server, on your own domain, visitors stay recognized much longer. That gives you better personalization and more accurate data.
The cookie domain is taken from your account's primary website domain.
Before you start
It sounds more technical than it is. All it takes is a path on your site (/tb by default) that forwards traffic to Triggerbee. This is called a reverse proxy. How you set it up depends on your platform, so you may need help from a developer.
You also need admin rights on the Triggerbee account to turn the feature on.
Beta feature: We're still improving this feature and will update this article continuously. Questions or stuck? Contact [email protected], and we'll help you.
Step 1: Set up your proxy route
The goal is for requests to https://yourdomain.com/tb/... to be forwarded to Triggerbee, along with the visitor's IP address and the hostname they're browsing.
Easiest: Cloudflare Worker
If you use Cloudflare, you can do this with a Worker, without touching your main server:
We recommend using a static IP address with Cloudflare, which is normally available on the Enterprise plan.
Create a new Worker in Cloudflare.
Paste the script below. If you want a different path than
/tb, just changePREFIX. Nothing else in the script needs changing.Add the Worker to your domain.
Example
// Serves Triggerbee from your own domain
// Set PREFIX to where you want it mounted. Nothing else in this file needs changes
const PREFIX = '/tb';
const UPSTREAM = 'https://t.myvisitors.se';
const TRACKER_PATHS = /^\/(js(\/\d+)?|(3\/|4\/)?t|visitor-state\/[a-z-]+(\/[a-z-]+)*)$/;
const EVENT_PATHS = /^\/((3\/|4\/)?t)$/;
const SKIPPED_HEADERS = new Set([
'connection', 'keep-alive', 'proxy-authenticate', 'proxy-authorization',
'te', 'trailer', 'transfer-encoding', 'upgrade', 'host',
'authorization', 'x-csrf-token', 'x-xsrf-token', 'x-forwarded-for',
]);
export default {
async fetch(request) {
const url = new URL(request.url);
if (url.pathname !== PREFIX && !url.pathname.startsWith(`${PREFIX}/`)) {
return fetch(request);
}
const path = url.pathname.slice(PREFIX.length) || '/';
if (!TRACKER_PATHS.test(path)) {
return fetch(request);
}
const headers = new Headers();
for (const [name, value] of request.headers) {
if (!SKIPPED_HEADERS.has(name.toLowerCase())) {
headers.set(name, value);
}
}
headers.set('X-Forwarded-Host', url.host);
headers.set('X-Forwarded-Proto', url.protocol.replace(':', ''));
headers.set('X-Client-IP', request.headers.get('CF-Connecting-IP') ?? '');
const upstream = new URL(path + url.search, UPSTREAM);
let response;
try {
response = await fetch(upstream, {
method: request.method,
headers,
body: request.method === 'GET' || request.method === 'HEAD' ? undefined : request.body,
redirect: 'manual',
});
} catch {
return new Response('', { status: 502 });
}
const out = new Headers(response.headers);
out.delete('set-cookie');
for (const cookie of response.headers.getSetCookie()) {
out.append('set-cookie', cookie);
}
if (EVENT_PATHS.test(path)) {
out.set('cache-control', 'no-store');
}
return new Response(response.body, { status: response.status, headers: out });
},
};
Not using Cloudflare?
The same approach works on most platforms where you can set up a reverse proxy, for example:
Vercel, Netlify or Next.js: using rewrites or edge functions.
Your own servers (Nginx, Apache, IIS): a proxy rule for
/tbthat points tohttps://t.myvisitors.se.AWS, Fastly or another CDN: using edge functions, such as Lambda@Edge or Fastly VCL.
Whatever the platform, the proxy must:
pass the visitor's IP address in the
X-Client-IPheader,pass the domain the visitor is browsing in
X-Forwarded-Host(and the protocol inX-Forwarded-Proto),pass Triggerbee's
Set-Cookieheaders back to the browser unchanged.
Use the Cloudflare script above as a reference.
Test the proxy
Open https://yourdomain.com/tb/js?site_id=YOUR_SITE_ID in your browser. If you see JavaScript code, the proxy works.
Step 2: Update your tracking code
You don't need to rewrite your tracking. The only thing that changes is the address the script is downloaded from.
Replace the Triggerbee address in the script URL of your existing tracking code:
From:
https://t.myvisitors.seTo:
https://yourdomain.com/tb
Reload your site and open the browser's network tab (Network). The Triggerbee script should now load from your own domain.
Using Google Tag Manager? You can't use the Triggerbee GTM Template to install Triggerbee with server-side cookies. Add the tracking code as a Custom HTML tag in GTM instead, or directly in your source code. The event tracking templates work as normal.
Step 3: Turn on server-side cookies in Triggerbee
Important before you save: Only turn the setting on once steps 1 and 2 are done and tested. If you turn it on before Triggerbee is served from your own domain, Triggerbee loses what it remembers about your visitors. Turning it on is also a one-way change; see Backwards compatibility below.
Go to My Triggerbee > Account settings.
Under Web Tracking, turn on Use server-side cookies.
Click Save and confirm the change in the dialog.
Done! Triggerbee now sets its cookies from your own server. Your existing visitors are carried over automatically the next time they load a page.
Backwards compatibility
From client-side to server-side cookies: safe. Your existing visitors are carried over automatically on their next page load. You don't need to do anything.
From server-side back to client-side cookies: not possible without data loss. If you turn the setting off again, the stored visitor history is lost.
Treat the switch as a one-way change. Only make it once you're sure you want to keep serving Triggerbee from your own domain.
Limitations
Server-side cookies only work on your account's primary website domain and its subdomains. New visitors on your additional domains may not be tracked.
