营销访问在边缘被第一方记录,并在会话之间传输,然后与消息队列中异步到达的转化匹配,然后按照计划进行调节,以捕捉实时路径错过的内容。 这是我们的代码,因此当数字看起来不对时,我们可以了解原因。
| 措施 | 价值 | 资料来源 | 已计量 |
|---|---|---|---|
| 编写和运行归属组件 | Ingest controller, ingest worker, conversion consumer, scoreboard service, reconciliation job | marketing package in the media service source tree | |
| 设置访问者标识符的位置 | First-party, by edge middleware on the site's own domain | marketing tracking implementation in the marketing site and media service | |
| 分析托管 | Self-hosted on our own cluster | kubectl get deployments -n kamo | |
| 转换交付机制 | Message queue consumer with a scheduled reconciliation pass | marketing conversion consumer and reconcile job |
它教会了我们什么建筑
一般的安排是,代理商粘贴标签管理器代码段,从那时起,每个关于数据的问题都会在仪表板上结束,而这些数据都不受任何一方的控制。 第三方 Cookie 被删除,广告拦截器删除更多数据,而实际发生的情况和记录的情况之间的差距每年都在扩大。
我们的路径是第一方的,访问标识符是由我们自己的域上的边缘中间件设置的,而不是由他人的脚本设置的。 归属在会话结束后仍然存在。 转化作为事件发布,并由工作者消耗,而不是内联计数,这意味着缓慢的转化路径不会减慢客户的速度,丢失的消息可以恢复 — — 存在调节任务正是因为不信任实时路径的完整性。
我们的网站有一个自我排除机制,这样我们自己的员工浏览的网站不会出现在营销数据中,它必须主动删除访问者cookie,而不是仅仅停止记录,或者已经记录的访问留在数据中。 滚动是所有时间,而窗口数字是从底部的行计算,因为两者不一致,假装相反会产生一个记分牌,不能与其自身的细节调和。 这些都是让仪表板值得信赖的东西,并且从外部看不见。
分析功能在同一群集上自我托管,因此页面级数据也是我们的。 对于客户,我们在客户自己的帐户中设置所有这些功能 — — 关键是您拥有衡量数据,而不是我们。
建于
- NATS JetStream
- Java
- Spring Boot
- Next.js middleware
- Umami
- YugabyteDB