Deliverables
Post Orientation - Office Hours
2 min
You can find the Office hour recordings and any material or links to support your post-demo validation.
Brandon walked the team on today's usage of Adobe Journey Optimizer. Juan suggested the necessary approach to get started in Campaign Orchestration using the setup they currently have in AEP.
Recording:
Validation Topics:
Show case Direct Mail.
Answer these questions:
- I’ve created a few schemas that I feel could work for our email operations. I’d like to show that to you and have you validate if I am on the right path.
- Let's review the schemas together.
- Does every schema need an identity and a primary key?
- Only those schemas that are required for blasting require an identity, but all model schemas need a primary key and a version column. Documentation
- If we are looking to create a table that is strictly used for storing personalization values, should we create a relational table or a dataset enabled for lookup?
- Example: In an email, we want to dynamically populate a URL based on the itinerary name that the guest is booked on. We would want to have a table that maps itinerary name to custom URL. Should that be a table in the relational store? Or a dataset enabled for lookup?
- This example is perfect for dataset lookups from what you showed me during session 1 of office hours.
- One of the schemas that I created should be profile enabled, but I am not seeing that as an option. Is that because we’re in a demo environment? Brandon_Profile_Schema_Example
- These datasets are not required for profile as the data doesn't need to be attached as a profile fragment. The only thing you enrich the profile with using the linking of identity in your model schema are the Message Feedback and Tracking experience events.
- I am trying to create a dataset for this schema but am receiving the following error:
- This error stems from the fact that your model lacks a version identitifier and if you want to maintain updating those records, then you must also include (Documentation) :
- A version identifier, such as a lastmodified field of type datetime or number.
- For Change Data Capture (CDC) ingestion, a special column named _change_request_type of type String, which indicates the type of data change (e.g., insert, update, delete) and enables incremental processing. Note that _change_request_type should not be part of the table schema, it should only be added to the data file during ingestion.
Next Steps
Booking Schema Uniqueness Workaround: Validate with the team whether creating a serialized unique contact ID prior to ingestion is the recommended workaround for booking schemas requiring uniqueness, and confirm feasibility of this approach. Investigate Composite Keys use case state. (Juan) Custom Action Node and API Availability: Advise on alternate solutions or workarounds for the absence of API-based custom action nodes in campaign orchestration and update on any plans for API availability. (Juan) Permission Error in Federated Composition: Follow up with Shey to resolve the permissioning error encountered during the creation of federated compositions in the FAC lab. (Shey)
Scheduling Next Office Hours: Send an email and meeting invite to schedule the next office hours session with the team. (Juan/Brandon)
Recording:
Validation Topics:
- Versioning Requirements and Data Ingestion: Juan explained to Brandon Farraye, Kyle, and the team the requirements for versioning in the data ingestion process, emphasizing the need for a version column (date, time, or number) and a change data capture column, and discussed the implications of using system-generated timestamps versus source data for versioning.
- Version Column Specification: Juan clarified that the version column in the ingestion schema can be a date, time, or number, and is used to track the latest state of a record; the change data capture column must be a string indicating insert, update, or delete operations.
- Ingestion Process Mapping: During the ingestion process, users must explicitly map the version column in their schema, and enabling change data capture is only available for relational schemas, as demonstrated by Juan using a Snowflake table example.
- System-Generated Timestamps: Juan advised against using system-generated 'now' timestamps during ingestion, explaining that this approach artificially marks all ingested records as the latest, which may not reflect the true recency of the data as known by the source system.
- Practical Use of Version Field: Brandon inquired about the practical application of the version field, to which Juan responded that it is standard in systems like Adobe Campaign for maintaining records without full table replacements, and that the current workflow may require augmenting data tables or creating new views to support this paradigm.
- Audience Building and Workflow Differences: Juan, Sheyla, and Imran discussed with Brandon Farraye and Kyle the differences between building audiences using relational schemas in campaign orchestration versus the traditional audience portal, highlighting the need for new workflows and potential training for the team.
- Relational vs. Profile-Based Audiences: Juan and Sheyla explained that audiences built from relational schemas are managed within the orchestrated campaign canvas, while the audience portal references only the data lake, profile store, and identity service, making the two approaches distinct and non-interchangeable.
- Workflow and Query Functionality: Juan described that campaign orchestration offers more advanced query capabilities compared to the segment builder, allowing for complex workflows and the ability to join multiple entities, whereas the rule builder operates on a flat, document-based profile schema.
- Migration and Training Needs: Juan and Kyle noted that transitioning to campaign orchestration will require the team to adapt their processes, document changes, and potentially undergo additional training to leverage the new workflow engine and relational data structures.
- Audience Reuse and Limitations: Brandon raised concerns about reusing audiences across workflows, and Juan confirmed that, currently, audiences built from relational schemas must be created within each workflow, and cannot be referenced in multiple workflows as with the audience portal.
- Custom Action Logging and System Data Export: Juan and Imran addressed Brandon Farraye's questions about maintaining custom action logging in campaign orchestration, explaining the limitations of custom actions in batch processing and recommending the use of system datasets and campaign tags for logging and data export.
- Custom Action Limitations: Juan explained that campaign orchestration does not support custom actions in the same way as journeys, due to the batch nature of processing, which makes per-user API calls impractical for large audiences.
- System Dataset Logging: All activity resulting from campaign orchestration is logged in AGO system datasets, including message feedback, tracking, and campaign metadata, which can be exported for reporting and analysis.
- Metadata and Tagging Solutions: Imran suggested that metadata such as product line can be captured by adding campaign tags or encoding information in campaign titles, which can then be queried and exported as needed for downstream systems like Power BI.
- Scheduled Queries for Data Export: Imran described how clients typically run scheduled queries against AGO datasets to extract, transform, and export measurement data, using fields like 'updated at' and campaign tags to filter and join relevant information.
- Transition Planning and Access Management: Brandon Farraye, Juan, and the team discussed the need for internal documentation, transition planning for new workflows, and the timeline for continued access to the platform and related resources.
- Documentation and Change Management: Brandon emphasized the importance of documenting current versus new processes to support the transition to campaign orchestration, especially given the complexity of their business model and the anticipated workflow changes.
- Platform Access Extension: Juan agreed to provide Brandon and the team with a few extra days of access to the platform, pending internal scheduling, and committed to notifying them by email when access would be removed.
- Resource Availability: Juan confirmed that all use case documentation, DDL files, and sample data are available on the team's website for future reference, and that the session recording would also be posted there.
Next Steps:
- Platform Access Extension: Check and confirm the extended duration for platform access and notify Brandon via email when access will be removed. (Juan)
- Internal Documentation Preparation: Develop internal documentation comparing current processes with new processes for campaign orchestration adoption, focusing on workflow changes and business model challenges. (Brandon Farraye)
- Custom Action Metadata Tagging: Add campaign-specific metadata (e.g., product line) as a campaign tag or in the title to enable querying and exporting for reporting needs. (Brandon Farraye)
- Reference Materials Distribution: Post the session recording on the designated website and ensure the team is notified when access will be removed. (Juan)