是否可以获取设备从接近信标 API 接收 URL 的次数?我想知道广播 URL 的点击率是多少。
3 回答
那要看。如果您编写自己的应用程序来扫描 Eddystone-URL 信标并从中触发一些内容(例如,网页本身),那么您自然可以完全控制并实施这种分析。虽然它只适用于安装该应用程序的人。
如果您依靠iOS 版 Chrome或Physical Web iOS 和 Android 应用程序来发现 Eddystone-URL 信标,那么这些应用程序不会提供任何此类数字。
但是,iOS 版 Chrome 和 Physical Web 应用程序确实会获取有关它们检测到的 URL 的一些元数据,例如页面标题和页面描述,而无需用户首先单击链接。因此,您极有可能过滤掉此类请求(它们将由Physical Web Service或类似的“机器人”发出),将它们与实际访问区分开来,并据此进行分析。然而,最有可能的是,这个“机器人”或代理服务(正是为了防止这种跟踪,并保护用户的隐私)也会做一些缓存,所以你会看到比实际数量更少的请求设备接收 URL 的次数。
最后,降到较低的级别,注意:大多数信标是单向的,即它们广播信息,但不接收任何返回的信息,因此信标本身通常无法计算接收端的数据包数量. (我想你可以在技术上使用蓝牙“扫描响应”机制来做到这一点,但它需要自定义信标硬件/固件。)
不幸的是,不,它自己不会这样做。
Google 的 Proximity Beacon Api 是一个服务器端系统,用于存储有关信标的元数据(位置、电池电量等)它需要您添加与您的应用程序集成的特殊客户端代码以提交检测数据。
同样,检测 Eddystone-URL 信标通常需要您向应用程序添加自定义代码来进行检测并将 URL 呈现给用户。(唯一的例外是某些启用了 Chrome Today 小部件的 iOS 版 Chrome 用户,并且没有公共系统提供点击率。)
由于您的应用程序必须显示 URL 本身,因此您确实必须推出自己的解决方案来解决此问题。
如果我理解正确,您应该可以通过 Google 分析活动来实现这一目标。设置一个活动,将活动 url 添加到 ibeacon url,您应该能够通过谷歌分析检查详细信息分析。