问题 (The Problem)

• My startup — One — is a digital challenger bank for the middle class, helping them get more for their money.

  我的初创公司One –是面向中产阶级的数字挑战者银行，可帮助他们从自己的钱中获得更多。

• A critical area lacking in the banks available to consumers today are personalized communications about what is happening with their money.
  如今，可供消费者使用的银行中缺少的一个关键领域是有关他们的钱正在发生什么的个性化通信。
• Knowing the answers to questions like ‘what are my new transactions?’ ‘How much do I have saved? ‘To spend?’ ‘Left to spend until my next paycheck’ are critical for consumers to manage their finances more efficiently.
  了解诸如“我的新交易是什么？”之类的问题的答案。 '我存了多少钱？ '要花？' “花钱直到下一次薪水支付”对于消费者更有效地管理财务至关重要。
• While we know these communications are important, we needed a scalable way to deliver them and quickly adapt to changing messaging needs on the fly, all while allowing our smaller engineering teams to focus on the core money movement aspects of banking that can help our customers achieve their financial goals.
  尽管我们知道这些通信很重要，但我们需要一种可扩展的方式来交付它们并快速适应瞬息万变的消息需求，同时让我们的小型工程团队专注于银行业务的核心资金流动方面，以帮助我们的客户实现他们的财务目标。
• Transactional data and needs change rapidly, as customers adopt different spending, saving and investing products giving rise to new data-types and possible communications.
  交易数据和需求Swift变化，因为客户采用不同的支出，储蓄和投资产品，从而产生了新的数据类型和可能的通信方式。
• Supporting each new use case, as well as the testing required to get the content, prioritization and timing right for each message and customer is a full-time job that becomes difficult to keep-up with balancing the big foundational changes our product aims to deliver.
  支持每个新用例以及正确获取每条消息和客户的内容，优先级和时间所需的测试是一项全职工作，很难与我们产品旨在提供的重大基础变化保持平衡。

机会 (The Opportunity)

• What we needed was a flexible framework to adjust to changing data-types on needs on the fly.
  我们需要的是一个灵活的框架，可以根据需要随时调整以适应不断变化的数据类型。
• This system needs to do 3 things:
  该系统需要做三件事：

1. support any new customer or transactional data we see for both triggering and populating messages with personalized content.

1.支持我们看到的任何新客户或交易数据，以触发和填充具有个性化内容的消息。

2. Allow us to process and compute the raw data into a messageable format.

2.让我们处理原始数据并将其计算为可发消息的格式。

3. Support the whole process without requiring engineering every time we need new data or want to process the data in a new way for a new message type.

3.支持整个过程，而无需在每次我们需要新数据或希望以新方式处理新消息类型的数据时都进行工程设计。

产品 (The Product)

• A personalized realtime message center in our product providing customers the most relevant information since they last logged in.
  我们产品中的个性化实时消息中心为客户提供自上次登录以来最相关的信息。
• Our definition of relevance is constantly evolving as new data types and use cases emerge.
  随着新数据类型和用例的出现，我们对相关性的定义也在不断发展。

Under the hood

引擎盖下

• The message center is powered by a real time event stream of user & transactional data fed in by our event bus Segment, which in-turn collects data from our Apps, APIs and 3rd party services.
  消息中心由事件总线网段提供的用户和交易数据的实时事件流提供支持，该事件流又从我们的Apps，API和第三方服务收集数据。
• We have a standard taxonomy for data-capture that satisfies requirement #1 capturing all new data from our sources.
  我们有一个用于数据捕获的标准分类法，它满足从原始资源捕获所有新数据的要求＃1。
• From Segment, this data is fed into our communications tool Braze to trigger messages and populate the content inside of those messages.
  这些数据从细分中被馈送到我们的通讯工具Braze中，以触发消息并填充这些消息中的内容。
• The data feed streams events in a standardized but raw format that requires a bit of massaging and computation before being used for messaging.
  数据源以标准的原始格式流式传输事件，在用于消息传递之前，需要一点点按摩和计算。
• We use 2 computational languages to process the data before being used for messaging — both of which are abstracted from engineering with their own GUIs — satisfying requirement #3.
  我们使用2种计算语言对数据进行处理，然后再将它们用于消息传递-两者均从具有自己的GUI的工程学中抽象出来-满足要求＃3。
• We use SQL through an abstracted rules engine in Segment that combines events and properties together to create new data types and cohorts of users.
  我们通过Segment中的抽象规则引擎使用SQL，该引擎将事件和属性组合在一起以创建新的数据类型和用户群。

• We use Liquid Syntax — a computational language written in Ruby — to process and transform the data before triggering messages or using data within the message.

  我们使用Liquid语法 (一种用Ruby编写的计算语言)在触发消息或使用消息中的数据之前处理和转换数据。

• The Liquid Syntax is applied directly in each message template — allowing our product and marketing teams to rapidly test and deploy new content and types of messages within waiting for each use case to be prioritized by engineering.
  Liquid Syntax直接应用在每个消息模板中，从而使我们的产品和营销团队可以在等待每个用例被工程确定优先级的情况下，快速测试和部署新的内容和消息类型。
• Within each message we can set key-value pairs to determine the relative priority of the message within a customer’s message center, email or push queue.
  在每条消息中，我们可以设置键值对来确定消息在客户的消息中心，电子邮件或推送队列中的相对优先级。

让我们看一个例子 (Let’s take a look at an example)

• We send customers messages every time they log-in about what’s changed since they were last here.
  自客户上次登录以来，我们会在每次登录时向他们发送消息。
• This could be the # of or $ value of their purchases, deposits, interest earned, payments due or other activity on their account.
  这可以是他们的购买，存款，赚取的利息，应付款项或帐户中其他活动的＃或$值。
• There are endless permutations of which transactions are relevant to a given customer.
  与给定客户相关的交易有无尽的排列。

• Certain transaction types hold more or less importance at certain times (ex. a purchase taking you account below the amount needed to cover a recurring bill due tomorrow), or have different meanings based on their metadata (ex. micro-deposits — 2 small transactions made by the external bank that the customer has to confirm the amounts of to confirm they are the owner of the account they want to connect)

  某些交易类型在某些时候或多或少地具有重要性(例如，一笔购买交易使您的帐户余额低于明天到期的定期账单所需的金额) ，或者根据其元数据具有不同的含义(例如， 微存款 -2笔小交易)由外部银行做出，客户必须确认金额以确认他们是他们想要连接的帐户的所有者)

• Customers looking to connect their One account to another bank may be required to do so using micro-deposits — 2 small transactions made by the external bank that the customer has to confirm the amounts of to confirm they are the owner of the account they want to connect.

  想要将其一个帐户连接到另一家银行的客户可能需要使用小额存款进行此操作 -由外部银行进行的2笔小额交易，客户必须确认这些金额以确认他们是他们想要的帐户的所有者连接。

• The problem is that these micro-deposits are not instant, and occur sometime 1–3 days after the customers want to connect their account.
  问题在于，这些微额存款不是即时的，而是在客户要连接其帐户后的1至3天左右发生的。
• We discovered a chunk of new customers were dropping off before funding their One accounts because of this asynchronous micro-deposit process.
  我们发现，由于这种异步微存款流程，大量新客户在为他们的One帐户注资之前就退出了。
• We wanted to notify them as soon as these micro-deposits showed up in their One account.
  我们希望在这些微型存款出现在他们的One帐户中时通知他们。
• Without our messaging framework, we would have had to prioritize work within our engineering cycles to build logic that looked at small transactions that might be micro-deposits and notify customers when this occurred.
  如果没有我们的消息传递框架，我们将不得不在工程周期内确定工作的优先级，以建立逻辑来查看可能是微存款的小型交易，并在发生这种情况时通知客户。
• With our messaging framework, we wrote some conditional logic in minutes using SQL & Liquid to alert customers and help them link their financial institutions.
  通过我们的消息传递框架，我们使用SQL＆Liquid在几分钟内编写了一些条件逻辑，以提醒客户并帮助他们联系其金融机构。
• The best part is that we are able to frequently update this logic without disrupting engineering cycles. As we get more signal about what micro-deposits, or other unique transaction types look like — refining by amount types, transaction_descriptors, and time of day — to better distinguish from real transactions and help customers fund their accounts faster.
  最好的部分是，我们能够在不中断工程周期的情况下经常更新此逻辑。 随着我们获得更多有关微存款或其他独特交易类型的信号(按金额类型，transaction_descriptor和一天中的时间进行细化)，可以更好地与真实交易区分开来，并帮助客户更快地为其帐户注资。

我们是怎么做到的 (How we did it)

To build this message we used a series of ‘If → Then’ conditional statements in Liquid to show customers the right message based on attributes of their recent deposit activity.

为了构建此消息，我们在Liquid中使用了一系列“ If→Then”条件语句，以根据客户最近存款活动的属性向客户显示正确的消息。

To walk through our example I’ll break down each logical statement into a Question we can answer using Liquid & SQL.

为了遍历我们的示例，我将把每个逻辑语句分解为一个我们可以使用Liquid＆SQL回答的问题。

How many deposits has the user had since they last logged in?

自上次登录以来，该用户有多少笔存款？

When did the user last login?

用户什么时候上次登录？

• Build a custom user attribute using SQL with their most recent login event timestamp. (something vaguely like the below query)
  使用SQL及其最近的登录事件时间戳来构建自定义用户属性。 (类似下面的查询)

When does a customer’s most recent deposit become available?

客户的最新存款何时可用？

• Deposit events contain hold end-dates, when the money will actually become available within a customer’s account.
  存款事件包含保留结束日期，这笔钱实际上将在客户的帐户中可用。
• We need to create an attribute that gives us the most recent hold end-date for a customer’s deposits.
  我们需要创建一个属性，为我们提供客户存款的最近保留日期。

Is the most recent deposit already available? Or will it become available in the future?

最近的存款是否已经可用？ 还是将来会可用？

• We can compare the most recent deposit hold end date with today’s date and see whether the money is already available or will be further in the future.
  我们可以将最近的存款持有结束日期与今天的日期进行比较，看看这笔钱是否已经可用或将来会更多。
• To do this we need to convert timestamps into an integer we can compare in size using mathematical operators in Liquid.
  为此，我们需要将时间戳转换为整数，我们可以使用Liquid中的数学运算符比较大小。

• Using the ‘date’ filter ‘%s’ argument to return the Unix time value for the timestamp we can values like 2020–06–06T16:52:21.783Z to values like 1591463299 which can be evaluated using a > or < operator.

  使用“日期”过滤器“％s”的参数为时间戳返回Unix时间值，我们可以像2020-06-06T16值：52：21.783Z到其可以使用>或<操作员来评价像1591463299值。

• If today’s date is > the most recent deposit hold end date (aka the deposit hold end date occurred before today’s date), then we know the money is available.
  如果今天的日期>最近的存款持有结束日期(又称存款持有结束日期发生在今天的日期之前)，那么我们知道这笔钱可用。

• If not we can abort this specific message and instead show the customer a message about when the deposit is expected to be available.
  如果没有，我们可以中止此特定消息，而是向客户显示一条有关何时可以提供保证金的消息。

If at least one recent deposit is available, has it occurred since the customer last logged-in to the app? (aka they have already seen a message about their deposit or not?)

如果至少有一笔最近的存款可用，这是否自客户上次登录该应用程序以来发生？ (aka他们是否已经看到有关存款的消息？)

• Compare these timestamps with the most recent login timestamp
  将这些时间戳与最新的登录时间戳进行比较

• Convert timestamps to an integer we can compare in size using mathematical operators in Liquid.

  将时间戳转换为整数，我们可以使用Liquid中的数学运算符比较大小。

• To do this we can use the date filter %s argument to return the Unix time for the timestamp
  为此，我们可以使用日期过滤器％s参数返回时间戳的Unix时间。
• If either the most recent RDFI or ODFI deposits were more recent than we need to show the customer a message letting them know money was added. Otherwise we need to not show the message, and let any other lower priority content in the queue display.
  如果最近的RDFI或ODFI存款比我们最近需要的存款要多，我们需要向客户显示一条消息，让他们知道有钱存入。 否则，我们无需显示消息，而让队列中显示其他任何较低优先级的内容。

If at least one deposit is available, how many deposits in total have occurred since last log-in?

如果至少有一笔存款，自上次登录以来总共发生了多少笔存款？

• We could use a count query in SQL in our rules engine in Segment to count the unique deposits, however any time-based computations run every 15 minutes and are not real time.
  我们可以在细分中的规则引擎中SQL中使用计数查询来计算唯一存款，但是任何基于时间的计算每15分钟运行一次，而且不是实时的。
• If a customer is logging in directly from a deposit email or push notification, we need to be confident all recent deposits are shown.
  如果客户直接从存款电子邮件或推送通知中登录，我们需要确保显示了所有最近的存款。
• To do this we have to rely more on Liquid processing at runtime rather than SQL.
  为此，我们必须更多地依赖运行时的Liquid处理而不是SQL。
• We’ll start with an attribute in the rules engine that stores all timestamps of the 50 most recent deposits as they come in.
  我们将从规则引擎中的一个属性开始，该属性存储50个最新存款的所有时间戳记。

• This array of timestamps is not ordered chronologically — so we need to cycle through all 50 values and compare each with the most recent timestamp value to determine if it should count as a recent deposit a customer needs to know about.
  该时间戳记数组未按时间顺序排序-因此，我们需要遍历所有50个值，并将每个值与最新的时间戳记值进行比较，以确定它是否应视为客户需要了解的最新存款。

• We’ll use a ‘for’ loop function to check each timestamp in the array of recent deposits and see if it is greater than or less than the Unix timestamp integer of the most recent login date.

  我们将使用“ for”循环函数检查最近存放的数组中的每个时间戳，并查看它是否大于或小于最近登录日期的Unix时间戳整数。

• If a timestamp is more recent we increment a new variable we’ve created to count each deposit, and then display that variable in the message to customers.
  如果时间戳记是最近的，我们将增加一个新变量，该变量是我们创建的以计算每次存款，然后在向客户的消息中显示该变量。

• This pattern can be repeated for any aspect of a deposit since last login — #, $ value, source of the funds, which account these funds are being added to, etc.
  自上次登录以来，对于存款的任何方面都可以重复此模式-＃，$值，资金来源，将这些资金添加到的帐户等。

Output

输出量

Is this deposit a micro-deposit that we should message differently?

这是我们应该以不同方式传达的微型存款吗？

Micro-deposits conform to the following structure

微存款符合以下结构

• The total $ amount is less than $1.00
  $的总金额少于$ 1.00
• They are followed by a debit for the sum of the 2 deposits to off-set the check
  然后是两个存款之和的借方借方以抵消支票

Knowing this pattern, we can write a little extra Liquid to identify potential micro-deposits and proactively reach out to customers when they occur.

知道了这种模式后，我们可以写一些额外的Liquid来识别潜在的微沉积物，并在发生时主动与客户联系。

• For transactions that are < 1.00 and of the type AchRdfi we can check if 1) the most recent deposit before this one was also < 1.00 and 2) if the sum of this deposit amount + the most recent deposit amount = the most recent debit amount.
  对于小于1.00且类型为AchRdfi的交易，我们可以检查1)此存款之前的最新存款是否也小于1.00，以及2)此存款金额+最近存款金额的总和=最近借方金额。
• If these criteria are met we can send the customer a notification to help them verify the account.
  如果符合这些条件，我们可以向客户发送通知，以帮助他们验证帐户。
• If not, we can abort the message.
  如果没有，我们可以中止消息。

结果 (The Outcome)

Building the message center in an abstracted way is allowing our team to move faster with fewer resources.

以抽象的方式构建消息中心可以使我们的团队以更少的资源更快地移动。

It has come with some risks, and placed more ownership on quality messages and building correct logic outside the engineering team.

它带来了一些风险，并将更多的所有权置于质量信息上，并在工程团队之外建立正确的逻辑。

In the long-run, we hope it will enable us to deliver more value to customers with fewer resources — allowing non-engineers to rapidly test and deploy new message types, and engineers to focus on larger value-adds.

从长远来看，我们希望它将使我们能够用更少的资源为客户提供更多价值-允许非工程师快速测试和部署新消息类型，并使工程师专注于更大的增值。