Bug: Referrer property incorrectly persists from the first event
Description:
There's an issue where the referrer property for a user profile is not updated after the first event. The initial referrer is incorrectly used for all subsequent events, even when the actual referrer changes.
Context:
Our web application is embedded as an iframe on multiple different websites. A single user can interact with our app from these various parent sites.
Problem Details:
The referrer for a user's events is consistently being set to the value from their very first event. Even when the user navigates to a new site, causing the sourceUrl (the raw referrer from the iframe) to change, the processed event in OpenPanel retains the original referrer.
I have confirmed the correct data is being sent by checking at multiple points:
- The initial API request to track the event contains the correct
__referrerproperty. - The resulting input event in the BullMQ queue correctly shows the updated
__referrerproperty. - However, the final output document in the BullMQ queue, or in the OpenPanel dashboard incorrectly shows the original, "stuck"
referrer.
Additional Notes:
- This issue is present on the latest commits (Even present on the commit just before the
events.incoming-event.tsL131-L153 changes, sha09c83ddeb415c8a400082fb086ed1b65109640f8). - The bug did not exist in the published self-hosted Docker version from a few months ago (v1).
BullMQ sample
{
"jobData": {
"type": "incomingEvent",
"payload": {
"projectId": "wallet-dev",
"headers": {
"user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36",
"openpanel-sdk-name": "web",
"openpanel-sdk-version": "1.0.1",
"openpanel-client-id": "xxxxx",
"request-id": "grBGcU1J"
},
"event": {
"name": "open-embedded-wallet",
"properties": {
"__referrer": "https://vanilla.frak-labs.com/",
"isIframe": true,
"isPwa": false,
"productId": "0x3b6376283043bc8049a0414dd85046fcb5ad21276d0eab9607b08027e7a513a6",
"sourceUrl": "https://vanilla.frak-labs.com/",
"metadata": {
"position": "left"
}
},
"timestamp": "2025-06-08T10:17:37.293Z",
"isTimestampFromThePast": false
},
"geo": {
"city": "Orgères",
"country": "FR",
"region": "Brittany",
"longitude": -1.6627,
"latitude": 47.997
},
"currentDeviceId": "270f2cbfd6784502502ae1bcef5aaf99",
"previousDeviceId": "3667b8ccbd549b3ee9f86231939ec3aa"
}
},
"returnValue": {
"document": {
"id": "7ad73d11-5bfd-4e73-82ed-58100f8d5601",
"name": "open-embedded-wallet",
"device_id": "270f2cbfd6784502502ae1bcef5aaf99",
"profile_id": "270f2cbfd6784502502ae1bcef5aaf99",
"project_id": "wallet-dev",
"session_id": "3e253904-12e0-4c23-9833-8738ffdccca1",
"properties": {
"isIframe": "true",
"isPwa": "false",
"productId": "0x3b6376283043bc8049a0414dd85046fcb5ad21276d0eab9607b08027e7a513a6",
"sourceUrl": "https://vanilla.frak-labs.com/",
"metadata.position": "left",
"__user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36",
"__reqId": "grBGcU1J"
},
"path": "/listener",
"origin": "https://wallet-dev.frak.id",
"created_at": "2025-06-08 10:17:37.293",
"country": "FR",
"city": "Orgères",
"region": "Brittany",
"longitude": -1.6627,
"latitude": 47.997,
"os": "Mac OS",
"os_version": "10.15.7",
"browser": "Chrome",
"browser_version": "137.0.0.0",
"device": "desktop",
"brand": "Apple",
"model": "Macintosh",
"duration": 0,
"referrer": "https://business-dev.frak.id",
"referrer_name": "",
"referrer_type": "unknown",
"imported_at": null,
"sdk_name": "web",
"sdk_version": "1.0.1"
}
}
}
Screenshot on the dashboard
This is by design. A session should only have one referrer (imo)
If you wait 30 minutes (when your session has timed out) you will see a new referrer (if any).
I would argue this is the most common why.
Your thoughts?
Yeah, I agree on this from a session attribution POV, and that's definitely the most common use case—just not ours haha
I think this edge case could be covered with a simple project setting that would disable the session attribution override. What do you think?
If you're open to the idea, I'd be happy to draft a PR and we can figure out the best way to implement it
Changing this is quite easy but not really sure (atm) on the implications across OpenPanel, in particular the overview page.
Here is the code where we override: https://github.com/Openpanel-dev/openpanel/blob/main/apps/worker/src/jobs/events.incoming-event.ts#L178-L180