---
title: POC Readout I
slug: vikingcruises-adobe-fac-poc/poc-readout-i
docTags: 
createdAt: 2025-11-21T18:28:19.509Z
---

::embed[]{url="https://player.vimeo.com/video/1139411051"}

*Generated by AI. Be sure to check for accuracy.*

### Meeting notes

- **Federated Audience Composition Use Cases:&#x20;**&#x53;heyla led the team, including Brandon Farraye, Alexandra Petrus, Andres, and Lana, through the main use cases for federated audience composition, focusing on accessing enterprise data sets in Databricks to federate, enrich, and activate audiences for personalization across channels.
  - **Business Case Overview:&#x20;**&#x53;heyla described two main business cases: targeting guests based on past booking and purchase behavior, and enriching profiles with propensity scores and federated attributes. The team defined four main audiences across these cases, including opted-in, booked-not-departed guests and those enriched with behavioral data and propensity scores.
  - **Audience Creation Patterns:&#x20;**&#x54;he team discussed three supported use case patterns: federating audiences without moving underlying data, enriching audiences with behavioral or existing AEP segment data, and profile enrichment to persist federated data inside an AEP profile.
  - **Daily Audience Refresh:&#x20;**&#x53;heyla explained the capability to schedule daily audience refreshes, demonstrating how attributes from Databricks data sets are federated and refreshed, and how additional attributes and experience events, such as logins to the My Biking Journey site, are layered for enrichment.
  - **Propensity Score Enrichment:&#x20;**&#x54;he team attempted to enrich audiences with propensity scores generated in Databricks and Customer AI, but encountered limitations due to insufficient historical data and profile counts in the development sandbox, preventing model training in AEP.
- **Implementation and Data Access Process:&#x20;**&#x53;heyla and Andres reviewed the technical steps for provisioning federated audience composition in AEP, including data dictionary development, mock data generation, service account authentication, and permission management for accessing Databricks and other data warehouses.
  - **Provisioning and Authentication:&#x20;**&#x54;he team provisioned federated audience composition in the AEP development sandbox, built custom parameters to expose only necessary tables, and authenticated access using service account credentials, with Andres handling UI authentication.
  - **Permission Requirements:&#x20;**&#x53;heyla highlighted the need for specific permissions, such as schema creation and table modification, to enable audience composition. The team resolved initial permission issues that restricted schema creation, allowing successful audience composition and query pushdown to Databricks.
  - **Schema and Table Management:&#x20;**&#x53;heyla explained that schemas in federated audience composition correspond directly to tables in the data warehouse, and users select columns and primary keys for exposure in the canvas. Schema updates, additions, and removals are managed within the UI and do not affect active workflows.
  - **Data Dictionary and Mock Data:&#x20;**&#x41; data dictionary was developed to define required tables, primary keys, and joins for the POC, and mock data was generated to correspond to these tables during the build-out period.
- **Data Modeling and Joins in Federated Audience Composition:&#x20;**&#x53;heyla and Andres discussed the creation of data models and links representing table joins, cardinality definitions, and the organization of schemas for audience composition, emphasizing the technical process for establishing relationships between tables.
  - **Model and Link Creation:&#x20;**&#x54;he team created multiple links within models to represent joins between tables, defining cardinality (one-to-one, one-to-many) and join types (left, right, outer) for the POC, with most relationships established as one-to-one.
  - **Schema Organization Strategies:&#x20;**&#x53;heyla described different ways to organize data models, such as separating person and non-person schemas, and provided examples of joining tables like contact view and travel summary by contact ID.
  - **Data Model Purpose:&#x20;**&#x41;ndres clarified that the data model is used solely to establish relationships between tables, with custom data elements and audience-building logic applied later during audience creation.
- **Audience Building and Query Logic:&#x20;**&#x53;heyla demonstrated the process of building audiences using the query builder, traversing joins, applying custom conditions, and mapping attributes for activation and personalization, while addressing questions from Brandon Farraye and Andres about audience counts and data reconciliation.
  - **Query Builder Usage:&#x20;**&#x53;heyla showed how to use the query builder to define custom conditions, traverse joins between tables, and preview audience definitions, highlighting the real-time calculation of qualifying profiles based on Databricks data.
  - **Audience Mapping for Activation:&#x20;**&#x54;he team mapped fields from compositions to identity namespaces, enabling audience activation in email and other channels, and discussed mapping additional attributes for downstream personalization.
  - **Audience Count Clarification:&#x20;**&#x42;randon Farraye asked whether the audience count reflects existing AEP profiles or records in Databricks; Sheyla confirmed it is the latter, and explained how AEP creates 'skinny profiles' when there is a delta between data warehouse and AEP profiles.
  - **Temporary Table Management:&#x20;**&#x41;ndres inquired about temporary tables created during query execution, and Sheyla explained that these are regenerated during active work and are automatically cleaned up after a 30-day retention period unless compositions are scheduled.
- **Complex Audience Enrichment and Reconciliation:&#x20;**&#x53;heyla detailed the construction of a more complex audience composition involving multiple nodes, activities like change dimension, intersection, split, and enrichment, and reconciliation of data from different tables, while addressing technical challenges encountered with mock data.
  - **Node and Activity Structure:&#x20;**&#x53;heyla built a composition with multiple nodes, using activities such as change dimension to switch source tables, intersection to combine outputs, and enrichment to tie together results from different nodes.
  - **Reconciliation Techniques:&#x20;**&#x54;he team reconciled data from tables without direct joins by changing dimensions and using intersection activities, and discussed the use of reconciliation activities for more complex rules.
  - **Split Activity for Date Comparison:&#x20;**&#x53;heyla used split activities to compare FM dates from different tables, defining pre and post conditions based on date logic, but encountered issues due to empty columns in mock data, resulting in no output for certain splits.
  - **Behavioral Data Layering:&#x20;**&#x54;he final step involved layering behavioral data, such as site logins, onto the federated audience composition, qualifying users based on both federated and behavioral criteria, and demonstrating real-time evaluation methods.
- **Scheduling, Governance, and Next Steps:&#x20;**&#x54;he team, led by Alexandra Petrus and Sheyla, coordinated scheduling for a follow-up meeting to cover remaining topics, including governance, guardrails, and technical access details, with Andres requesting documentation on roles and permissions for future environments.
  - **Follow-Up Meeting Planning:&#x20;**&#x41;lexandra Petrus and Sheyla discussed scheduling a follow-up session to review additional audiences, propensity scores, and governance considerations, ultimately agreeing on a time that accommodates all participants.
  - **Governance and Access Documentation:&#x20;**&#x41;ndres requested a recap and documentation of technical details related to user access and permissions for federated audiences in AEP, and Sheyla confirmed that governance topics would be addressed in the next meeting.

### Follow-up tasks:

- **Temporary Table Cleanup Confirmation:&#x20;**&#x43;onfirm with product team whether temporary tables in Databricks are automatically cleaned up after the default retention period or require manual cleanup, and communicate the findings to the team. (Sheyla)
- **Meeting Follow-Up Scheduling:&#x20;**&#x53;chedule a follow-up meeting for Monday at noon Pacific Time to continue the POC review and address remaining topics including audiences 3 and 3A, propensity scores, and governance considerations. (Sheyla, Alexandra Petrus)
- **Recording and Copilot Notes Distribution:&#x20;**&#x53;end the meeting recording and copilot notes to the team for review and further digestion. (Sheyla)
- **Federated Audience Access Documentation:&#x20;**&#x50;rovide documentation and a recap of the technical details and required roles/permissions for user access to Federated audiences in AEP, especially for transitioning to other environments. (Sheyla)
