Discuz! Board

標題: 关系一附加应用程序的实际用例 [打印本頁]

作者: ahad1020    時間: 2025-5-12 12:16
標題: 关系一附加应用程序的实际用例
我们都经历过这种情况。一项新的营销计划即将启动,目标、交付成果和预算都已获批准,项目正在顺利进行。然而,当你在 Eloqua 中设置技术解决方案时,却遇到了瓶颈。Eloqua 根本无法满足你的需要。

问题通常集中在数据及其在 Eloqua 中的存储方式上。Eloqua 内置的用于充分利用这些数据的工具可能有限。Relationship One 提供了一系列云应用,旨在解决这些问题。这些应用在项目和活动画布上运行,让您能够将关键数据存储在所需的位置。

在这篇文章中,我们将研究三个附加器应用程序(对象到联系人附加器、对象到对象附加器和 CDO 记录拆分器)如何克服现实世界中的场景,在这些场景中,Eloqua 的开箱即用功能可能并不适合所有用例。

使用Object-to-Contact 附加器进行同意管理
在这种情况下,一家公司需要引用自定义数据对象字段来管理其联系人的同意。问题是,该公司现有的 Eloqua 同意管理程序使用的是联系人字段,无法引用 CDO 中的数据。重新构建同意管理系统并非可行方案;数据必须存储在联系人字段中。虽然 Eloqua 能够获取 CDO 数据并将其附加到联系人字段,但一些关键的限制让该公司束手无策。对象到联系人附加器能够弥补这一缺陷,并确保系统平稳运行。

该公司的产品购买数据从其电商平台输入到 Eloqua 的 CDO,其中包含产品的购买日期。由于该公司在加拿大开展业务,因此根据 CASL 的默示同意规则,输入到 Eloqua 的许多电商记录都符合营销电子邮件的条件。默示同意从购买时开始生效,如果客户未选择加入,则会在一段时间后失效,因此记录购买日期至关重要。

挑战在于获取购买 日期,识别映射的联系人,乌拉圭电话号码库 并将该日期写入联系人表的字段。Eloqua 可以使用 CDO 记录服务和字段映射来实现这一点,但它处理的记录数量有严格的限制。新的记录​​(包括新的购买日期)进入 CDO 的速度太快,Eloqua 无法跟上,因此需要采用不同的方法。

对象到联系人追加器 (Object-to-Contact Appender)提供了此解决方案。该公司能够在 Eloqua 中设置一个程序,通过监听器 (Listener) 提取新的 CDO 记录。对象到联系人追加器应用在程序画布上运行,作为查找记录映射联系人的步骤,从 CDO 获取购买日期,并将其复制到联系人表中的“默示同意日期”字段中。

由于该应用程序在程序画布上运行,因此它几乎实时运行,能够处理公司经常遇到的流量高峰。新客户可以立即加入培育活动,并且可以自信地跟踪他们的默示同意期,从而确保公司始终符合 CASL 的要求。

使用对象到对象附加器的电子邮件签名
交叉引用位于不同 CDO 中的数据是另一个常见的挑战,当公司试图构建一组自定义签名放置在其营销电子邮件中时,就会面临这种情况。

该公司的销售团队规模庞大,拥有超过 1,000 名销售代表,覆盖 全球多个地区。人员流动率很高,销售代表一年内多次更换产品或地区的情况并不少见。因此,要确定电子邮件收件人应该在签名中看到哪位销售代表并非易事。

HR 部门每周提供一份更新的销售代表文件,其中包含他们的姓名、职位、联系方式以及其他用于签名的数据。这些数据存储在销售代表 CDO 中。同时,HR 部门还为客户设立了一个单独的 CDO,用于存储分配给客户的销售代表信息。HR 部门的目标是将来自 HR 部门的销售代表数据填充到客户 CDO 中的字段中,用于签名中的字段合并,但这两个 CDO 之间无法互相通信。

代表 CDO 使用代表 ID 作为唯一标识符,且记录未映射到联系人。客户 CDO 使用电子邮件地址作为唯一标识符,但将两个数据集连接在一起却是一项挑战。对象到对象附加器提供了一种快速高效的解决方案,解决了将代表数据从代表 CDO 提取到客户 CDO 的问题,从而支持电子邮件签名的字段合并。

它只需极少的配置,并且能够与公司现有的个性化模型完美兼容。最大的优势在于,它无需公司再去人力资源部门重新格式化每周的销售代表文件。它允许市场营销部门以现有数据的格式进行处理,同时提供市场营销部门所需的个性化服务。

使用CDO 记录拆分器支持交易电子邮件
在这个用例中,一家公司使用的合同管理软件每天向 Eloqua 提供新签订合同的信息。每份合同最多涉及 10 名员工,他们需要根据其角色和与公司的关系在不同时间收到合同通知。有些员工需要接收账单和付款信息,而有些员工则需要接收服务交付邮件。该公司面临的挑战是如何将合同信息推送到 Eloqua,以便所有利益相关者都能收到邮件。

传入的数据使用合同 ID 作为唯一标识符,并且利益相关者的电子邮件地址在每个合同记录中都是单独的字段。Eloqua 无法从每个合同记录中提取电子邮件地址并创建新的联系人来发送通知。

该公司能够使用CDO 记录拆分器来克服这一障碍。他们设置了一个父 CDO 来保存传入的合同数据。然后,他们创建了十个子 CDO,每个子 CDO 对应一个潜在的利益相关者。将所有这些连接在一起的是一个包含 10 个 CDO 记录拆分器步骤的项目画布。父 CDO 的新记录会进入项目画布,其中 CDO 记录拆分器步骤会将不同的利益相关者电子邮件地址“拆分”到相应子 CDO 中的新记录中。

从那里,原生的 Eloqua 功能能够为每个新的利益相关者记录创建一个映射联系人,并且公司能够清楚地识别利益相关者以及他们需要发送的特定电子邮件以支持公司的合同。

Relationship One Appender 系列应用提供了经济实惠且易于配置的解决方案,解决了 Eloqua 中一些较为棘手的数据限制问题。您将如何使用这些 Appender 应用?立即联系 Relationship One了解如何使用。





歡迎光臨 Discuz! Board (http://shiangwan.skybbs.cc/) Powered by Discuz! X3.3
一粒米 | 中興米 | 論壇美工 | 設計 抗ddos | 天堂私服 | ddos | ddos | 防ddos | 防禦ddos | 防ddos主機 | 天堂美工 | 設計 防ddos主機 | 抗ddos主機 | 抗ddos | 抗ddos主機 | 抗攻擊論壇 | 天堂自動贊助 | 免費論壇 | 天堂私服 | 天堂123 | 台南清潔 | 天堂 | 天堂私服 | 免費論壇申請 | 抗ddos | 虛擬主機 | 實體主機 | vps | 網域註冊 | 抗攻擊遊戲主機 | ddos |