Adobe 的跟踪 cookie 中根本没有个人身份或个人信息。
在我说任何其他内容之前，根据您所说的，我只想说，我认为您的安全委员会要么误解了 Adobe 的跟踪 cookie，要么不切实际地夸大了事情的比例。
访问者 ID (s_vi) cookie 就是这样：一个包含访问者 ID 值的 cookie。以下是 cookie 值的示例：
[CS]v1|2A933F6C05079103-6000110EA000D3F3[CE]
该值与访问者的个人信息或数据或类似内容无关。这是一个随机生成的值，只要 cookie 存在，它就会一直存在于访问者身上。
为您所做的任何自定义编码创建的 Cookie 都不是一回事
看，这就是我认为有些人可能会感到困惑的地方。这是一个常见的场景来解释：成员ID跟踪。访问者第一次访问您的网站时是匿名的。他们登录到您的网站，现在您的网站知道他们是谁。
从跟踪的角度来看，拥有反映这一点的 prop 和/或 eVar 是很常见的。因此，在您不认识访问者的页面/点击中，您不会弹出任何内容，或者您可能会弹出一些默认的“匿名”或“未知”或“注销”值。然后，当访问者登录时，您会弹出 prop/eVar，其中包含您的站点识别为成员或帐户 ID 的值。
也许这个 id 是他们的电子邮件地址。也许这是一个随机生成的值。也许它是一个用户名。关键是，它可以在您自己的站点系统中唯一地识别访问者。
假设您编写代码，在登录时弹出 prop1 的值，然后您决定使用 Adobe 的 getAndPersist 插件。这个插件基本上接受一个值并将其放入 cookie 中，然后在每次调用插件时检索该值。这里的想法是，您只需完成一次从最终得出价值的工作，然后 Omniture 将从那里坚持下去。当您希望为每个页面/点击弹出一个值但可能无法轻松访问以将逻辑复制或限定到站点的所有区域（尤其是跨子域）时，这特别有用。
所以现在您有一个由 Adobe Analytics 代码设置的 cookie。 这和 s_vi cookie 一点关系都没有。
首先，它是你明确设置的，即使它只是为了让球滚动。其次，该值没有存储在s_vi cookie 中；它存储在单独的第一方 cookie 中。
即使您有 FPC 跟踪，它仍然设置在单独的 cookie 中。实际的 cookie 名称取决于您使用的插件（或您自己使用 Adobe 的 s.c_w cookie 写入功能），以及您是否使用组合 cookie 插件（在这种情况下，它将被放入 s_sess 或 @ 987654328@，取决于你设置的过期时间）
现在.. 如果您确实实现了 FPC，您显然可以用您自己的值覆盖该 cookie。而且您显然可以使该值成为您想要的任何值，包括访问者个人的东西。但这不是 Adobe 的做法。那是你的在做的。
这里的总体要点是，无论您将访问者跟踪为第一方还是第三方，这都是一个完全独立的 cookie，与个人数据无关。
您可能有包含个人数据的自定义编码，并且您可以将这些数据放入 cookie，即使使用 Adobe Analytics 功能，但那不是一回事。永远都是第一方cookies（js不可能写第三方cookies），cookies永远是分开的。
尽管如此，s_vi 访问者 ID 可能被用于间接获取个人数据
我相信接下来听到的内容会是“但没关系，它是访问者的唯一 ID，它在 Adobe 中，其他数据也是如此，您可以使用访问者 ID 以在 Adobe 中查找数据！”
这是真的。不过……
首先，为了在 Adobe Analytics 中找到可识别个人身份的数据，您必须明确地将其放在那里。例如，你必须设置如下内容：
s.prop1='jon doe'; // name
s.prop2='4321 1111 1111 1111'; // credit card #
s.prop3='04/2020'; // exp date
s.prop4='123'; // security number
我认为我不应该告诉您这是一个非常糟糕的主意，但重点是，这不是 Adobe 收集该信息，而是 您 在这样做。而且它不在 s_vi 访问者 ID cookie 中，也永远不可能（同样，除非您有 fpc imp 并决定用这些值显式覆盖 cookie..）。
因此，这些数据连同访问者 ID 一起发送到 Adobe 服务器。所以有下一个障碍：在 Adobe 中访问数据。坏人必须在您的公司下拥有一个 Adobe Analytics 用户帐户，并且它必须具有适当的权限才能访问该数据。
即便如此，Adobe 并没有真正在报告中公开访问者 ID 值。因此，为了获取与某个访问者 ID 关联的数据，您需要访问数据仓库，或者被列为受支持的用户并从 ClientCare 请求原始命中日志。
我想这里的总体观点是，就其本身而言，访问者 ID 并不是真正危险的东西。这不是个人数据，并且能够利用它来查找与其相关的特定数据将首先涉及将个人数据存储在 Adobe 服务器上以及获得对所述服务器/接口的访问权限的极端愚蠢行为。
除此之外..
好的，所以也许你不关心上面的所有内容。或者也许这些都没有说服你的安全理事会让步。您正在远离 Adobe FPC imp，仅此而已。因此，让我们谈谈您列出的选项以及您对它们的担忧。
内部报告
你说这“太贵了”。你知道，我必须在这里说实话.. 这有点可笑，来自银行！不过说真的..
也许您认为从头开始构建的角度来看太贵了？如果是这种情况，您是否考虑过已经构建的选项，您可以将其放在自己的服务器上并从那里自定义或构建？
Webtrends 提供此功能。坦率地说，我讨厌将 Webtrends 作为跟踪解决方案，但它确实提供了将其放在您自己的服务器上的能力（无论如何，我最后一次听说）。此外，Piwik 是一个非常好的开源解决方案。
过滤代理
我不太清楚你的意思。这听起来很像 FPC 跟踪。除了有一种方法可以在所有个人数据请求发送到 Adobe 之前对其进行清理？好吧，如果是这样的话，我会回到首先将个人数据发送给 Adobe 的问题。但是，好吧，也许您没有这样做，而是想采取额外的预防措施以防万一；很公平。
因此，也许您在终端设置了一个服务，将所有请求发送到 stats.bank.com，它会清理内容，甚至可能具有值映射（例如访问者 ID）。原则上，这并不是一个复杂的脚本，所以我不得不再次想知道为什么成本是一个问题，尤其是来自银行......但无论如何......
坚持使用 Adobe 的 3rd 方 cookie 实施
如果您想使用 Adobe 拥有的域返回 3rd 方 cookie 跟踪，而不是使用默认的 2o7.net 域，我建议您考虑为 Regional Data Collection 实施新的（er）第 3 方 cookie。
滚动您自己的第 3 方 cookie 实施
据我所知，Adobe 不提供任何类型的服务，涉及您为 他们 指定域名以作为第 3 方实施购买/拥有和收集数据。
最接近此的服务是第一方 cookie 跟踪。所以，如果你有www.bank.com，通常你会指定类似stats.bank.com（在根域上的东西），这就是FPC跟踪。
但是，您可以告诉 Adobe 使用例如 stats.someotherdomain.com（假设您拥有并控制它），他们可以为该域实施 FPC 跟踪。然后，当您在www.bank.com 上实施跟踪时，这实际上变成了第 3 方 cookie 跟踪。
但需要注意的是，您仍然拥有该域，所以我只能假设在 某些 级别上，您仍然会对此负责（我不是律师）。但是，也许这足以安抚您的安全理事会，值得向他们提出。