Introduction to Federated Audience Composition
10 Nov 2024 » Platform
In the last month or so I have noticed a developing interest in a new feature offered by Adobe Experience Platform: Federated Audience Composition. It has been some time in the making, a time during which I rarely heard about it. Now that it has been released, it looks like everybody wants it. Today I will explore what it is and what you can do with this capability. I will not explain how to configure it, maybe in a future post.
What is FAC?
We have to start by explaining what Federated Audience Composition (FAC) is. FAC is a feature that allows marketers to generate audiences directly on an enterprise database or data warehouses. In other words, instead of using Adobe Experience Platform (AEP) real-time customer profile data to generate audiences, you use the data present in an external data storage. This is why it is called federated.
In more technical terms, this is what FAC does:
- Takes an audience composition from the UI.
- Generates one or more SQL statements.
- Sends the SQL statements to the database engine.
- Waits for the database to process the SQL and generate the result.
- Retrieves the result, which must contain an identity.
- Creates an audience with the profiles referenced in the result.
At the moment of writing, FAC supports Amazon Redshift, Azure Synapse, Google Big Query, Snowflake, Vertica Analytics, and Databricks. I assume more will be added in the future, as customers request it.
Use cases
Apparently, from what I have heard, multiple customers have requested this feature. AEP competitors offer this capability and it is very appreciated. I did not understand why until I heard some use cases that could be achieved with FAC. Let me know in the comments if you have any additional use cases.
Shorter time to value
If you have worked with AEP, you know that it takes, at the very minimum, 3 months to implement a workable solution. In fact, I have only heard this timeline once, with a customer that was completely ready from day 1 and had knowledgeable people on the team. Otherwise, you can easily expect 6 months. This means that, during 3-6 months, our customers cannot use this expensive toy that they have just purchased. I do not need to tell you that this is a lot of time without realizing any value.
With FAC you can start using AEP in a few weeks. You will only be able to use data in your federated data storage and with RTCDP destinations, but you can start getting value out of AEP sooner.
Sensitive data
The health and FSI verticals are heavily regulated. Other verticals are less regulated, but may still manage sensitive data. One of the consequences is that you may not be able to send all the data you would want to AEP. For example:
- Total asset value of an account.
- Credit score.
- Latest prescriptions.
- Health conditions.
Until now, if you wanted to create a campaign based on a parameter not present in AEP, you needed IT and marketing to work together to come up with a solution. With FAC, a marketer can create a segment in AEP based on data present only in the company-internal database, without sending any sensitive data to AEP. AEP only gets the resulting audience.
I personally find this one of the most powerful use cases.
Move workload outside of AEP
If you rely heavily on data distiller and batch segmentation, you will notice that these processes take some time. As you add more profiles, more queries, and more segments, the processing time increases.
One solution could be to offload some of those processes from AEP and move them to your database engine. This solution may not be possible in all cases though, so consider this as just another option.
One time segments
Sometimes you have to create a segment that you will use only once. If the data is already in AEP, great, go ahead and create it. However, if the data needs to be uploaded into AEP, you have a mini-project: create or extend a schema, maybe create a new dataset, extend ETLs, test the process… Is it worth doing all the work for a single, short-lived segment?
In most cases, the answer is going to be “no”. With FAC, you can just create that segment directly on your federated database for your single campaign and delete it after the campaign has finished.
Caveats
One of my customers asked me what the point of sending data to AEP was if you could just run FAC. This is a very valid question and I am sure many have thought about it. Here are some reasons why you still an implementation to send data to AEP:
- Batch only. By the very nature of relational databases and data warehouses, all processing is batch. Edge and streaming segmentation require the data to be present in AEP.
- Data needs. AEP’s segment engine is not the only place where profile data is needed. Adobe Journey Optimizer and Customer Journey Analytics, to name a couple, rely on profile attributes in many places.
- Database cost. You need to evaluate the cost of running additional SQL commands in your database. If you have it on-prem, it will have an impact on your hardware; if you have a cloud database, the provider will likely charge by the processing time. AEP, on the other hand, does not charge by the hour.
With these caveats, I want to make it clear that FAC is not a replacement for a full CDP implementation, it is just an additional tool under your toolbelt.
[UPDATE 17/11/2024] As pointed out by Ankur, FAC supports both relational databases and datawarehouses. Any usage of “database” in this post refers to a generaic data storage.