Channel 4 VOD Integration: DDD Model and 4+1 Architecture

Overview: Channel 4’s video-on-demand (VOD) ad ops process currently handles around 2,600 campaign bookings per month, but relies on fragmented inputs and manual workarounds. This leads to extensive copy chasing and even revenue loss when campaigns miss start dates due to missing ad copy. The following Domain Driven Design (DDD) model and 4+1 architectural views outline an integrated solution to bridge Linear and VOD campaign management. The solution retains existing systems (Prisma, CARIA, Stellar, Freewheel, etc.) but automates data integration and workflows using NLP and contextual embeddings and MCDA (for fuzzy matching), thereby reducing manual intervention, delays, and non-value-added tasks.

Stakeholders

• Media Buying Agencies: Plan and book campaigns. They input campaign bookings via Prisma (majority of cases) or directly in CARIA. They also provide a tracking tag for each campaign (multiple tags for targeting tactics) to monitor ad impressions.
• Creative Agencies: Produce the advertisement creatives and deliver Copy Rotation Instructions (which creative copy to run for each campaign) via CARIA. They also ensure the ad files are delivered (often via separate delivery platforms) and have proper clearance.
• Clearcast: Industry body that approves ads and issues a clearance ID (clock number) for each ad creative. All UK broadcasters require that each ad copy has a Clearcast clearance before airing. The clearance info (associated with the clock number) must be provided to the broadcaster’s systems. Clearcast also manages CARIA, the platform linking each ad version (clocked copy) with the media booking.
• Channel 4 Operations Team (Traffic): The internal team responsible for campaign trafficking and content readiness. They monitor incoming bookings, chase missing copy or tags, input clearance info into Freewheel, and ensure all prerequisites (“chase list” items) are completed so the ad can run. This team is the primary user of the new integrated workflow, which aims to streamline their processes (reducing manual data entry, copy chasing, and coordination with agencies).
• Ad Tracking/Verification Team (Tag Specialists): A specialist team (either within Channel 4 or an external auditor) that assigns third-party tracking tags at the campaign level for impression verification. Currently, tags are emailed and then manually entered into systems. In the new system, their workflow is integrated so that tags can be captured and applied automatically.

(Other stakeholders include the Advertisers (whose campaigns must start on time with correct creatives), and technology partners (ad serving platform providers, etc.), but the above are the key roles directly interacting with the campaign management process.)

Domain Model

The domain model identifies the core concepts (Entities, Value Objects, Events) and how they are grouped into Bounded Contexts. The operations team’s needs are central: ensuring a Campaign has all required pieces (booking, copy, clearance, tag) ready in time. Below is the candidate domain model:

Entities

• Campaign: The central entity representing an ad campaign booking/order. Contains campaign details (name, advertiser, start/end dates) and references to associated Copy and Tag. It is primarily created when a booking is received from the agency (e.g. via Prisma). A Campaign holds the Prisma PID as an identifier linking to the booking, and possibly a CARIA booking reference.
• AdCopy (Creative Copy): Represents a specific advertisement creative (video file) intended to air. Key attributes include a Clock Number (the Clearcast-issued clearance ID), creative title/description, and clearance status. An AdCopy may be associated with one or more Campaigns (if the same creative is reused), but in this context is usually tied to the campaign via copy instructions. The Clearcast clearance info (approval status and date) is associated with the AdCopy.
• TrackingTag: Represents a tracking beacon or tag applied to a campaign for third-party verification. Attributes include a Tag ID or code (often a URL or script provided by the agency’s tracking partner, e.g. Flashtalking or Google’s DCM) and possibly metadata like the provider name. Each Campaign is expected to have one Tag assigned to collect impression data.

(Other supporting entities could be defined, such as BookingOrder as a finer-grained entity for the booked line items, or CopyInstruction to model the linking of AdCopy into a Campaign with rotation rules. However, for this high-level model we treat the campaign’s copy assignment and tag as direct relations to Campaign.)

Value Objects

• PID (Prisma ID): A unique identifier for the campaign booking in the Prisma system. Treated as an immutable value object used to correlate data between Prisma/Stellar and other contexts.
• ClockNumber: The Clearcast clearance code for a given ad creative (e.g., a string like “CLEAR123456”). Uniquely identifies an AdCopy and is used across systems to match the creative. It’s a value object – essentially a key that should match between CARIA instructions and Clearcast/Freewheel.
• Tag Code/ID: The identifier or code snippet for the tracking tag. For example, it could be a GUID or the URL portion of the tracking pixel. It’s used as a value object to ensure the correct tag is applied; comparisons may use fuzzy matching if tags have variants.

(Other possible value objects: CampaignName (title of campaign), which might be used for fuzzy matching between systems if IDs are missing; BookingReference (Caria booking ID or Stellar ID); ClearanceStatus (an enum or status value indicating Clearcast approval).)

Domain Events

• BookingReceived: Triggered when a new campaign booking is received (e.g., from Prisma/CARIA into the system). Contains data like campaign name, PID, flight dates, etc. This event starts the campaign setup workflow.
• CopyValidated: Indicates that a creative copy for a campaign has been received and validated (correct clock number and clearance in place). This event is raised once the system confirms an AdCopy is ready (either by matching an existing linear copy or by ingesting a new file and checking clearance).
• TagAssigned: Indicates a tracking tag has been provided and linked to the campaign. For example, when the tag specialist’s input is captured (via email or an interface) and associated, the system emits TagAssigned.
• CampaignReady: (Derived event) Signifies that all requirements for a campaign are fulfilled (booking, copy, clearance, tag), so the campaign can go live. This could trigger final deployment of the campaign to the ad server (Freewheel).

(Additional events could include CopyMissing or TagMissing alerts to prompt action if deadlines near, but the above cover the primary happy-path milestones.)

Bounded Contexts

Using DDD, we group related concepts into contexts to reflect different subdomains of the overall process:

• Campaign Management Context: Handles campaign bookings and overall campaign lifecycle. It’s the source of truth for Campaign entities (bookings) and consumes BookingReceived events from Prisma/CARIA. This context is responsible for creating campaign records (with PID, metadata) and coordinating with other contexts to gather copy and tags.
• Copy Management (Validation) Context: Focused on creative assets and clearance. It receives copy instructions from creative agencies (via CARIA) and ensures a valid AdCopy is linked to the campaign. This context interacts with Clearcast for clearance verification and with content libraries. It emits CopyValidated when an ad copy is ready. (It essentially models the “Copy chasing and validation” process that operations used to do manually.)
• Tag Management (Monitoring) Context: Manages tracking tags for campaigns. It interfaces with the tag specialists or tracking systems to obtain the tag, and ensures it’s attached to the campaign. It may parse emails or integrate with a tag provisioning system. Emits TagAssigned when done, and can validate that the tag is correct/active.
• Ops Workflow/Orchestration Context: Overarching context that tracks overall campaign readiness. It listens for events from the other contexts (BookingReceived, CopyValidated, TagAssigned) and maintains the state of each campaign’s “chase list”. This orchestrator context can trigger actions (e.g., send reminders if copy or tag is late) and ultimately emits CampaignReady when everything is in place. It provides the Operations Team with a dashboard of campaigns and their status (which items are done or pending).

Below is a puml domain model diagram illustrating the key entities, their relationships, and context groupings:

(In the diagram above, a Campaign may include multiple AdCopy instances (e.g., for copy rotation) and at most one TrackingTag. The Value Objects (PID, ClockNumber, TagCode) are noted inline. Dashed lines or notes could be used to indicate domain events and their relation to entities. Bounded Contexts are shown as packages grouping the relevant entities.)

Logical View (Architecture)

The logical architecture identifies the main software components and their interactions. The proposed solution follows a microservice-oriented approach, aligning with the bounded contexts identified above. Key components include integration services for each context and an orchestration layer, all deployed in a cloud environment. The goal is to automate data flows between existing systems:

• Booking Integration Service (Campaign Service): Ingests campaign bookings from Prisma/Stellar and CARIA. When a new booking arrives (via API or data feed), this service creates a Campaign entity and publishes a BookingReceived event. It also pushes the campaign data to a central workflow (or state store) that the ops team can track.
• Copy Integration Service: Listens for copy rotation instructions from CARIA (via API or polling). Upon receiving a rotation with a clock number for a campaign, it tries to match that clock number or campaign name to the existing Campaign (using PID or fuzzy matching on metadata if needed). It then checks for the creative asset: if the asset is already present (e.g., re-using linear copy in Channel 4’s library), it can mark it as received; if not, it triggers a request for the file. The service also interfaces with Clearcast (e.g., using an API or data export) to verify the clearance certificate for the clock number, automating what was previously a manual Freewheel data entry step. Once the copy is confirmed and clearance is verified, it emits CopyValidated.
• Tag Integration Service: Handles the ingestion of tracking tags. It may provide a small interface or monitor an email inbox to capture the tag code that the media agency’s tracking team sends. Using NLP, it can parse emails or forms to extract the Tag ID/URL. This service attaches the tag to the correct campaign (matching by campaign name or ID) and emits TagAssigned. (If the tag is inconsistent with the campaign metadata, fuzzy matching or even manual confirmation via the ops dashboard could be used to ensure correctness.)
• Matching & NLP Engine: A supporting component that provides fuzzy matching and contextual lookup capabilities across services. For example, if a CARIA copy instruction comes in without a Prisma PID attached (one of the current challenges), this engine can compare the campaign name, advertiser, or other context from CARIA against the Prisma booking data to find the best match and link them. It may use text embeddings (to handle slight naming differences or typos between systems) to suggest or automatically perform the association. This engine is used by the Copy and Tag services whenever data needs to be correlated across systems lacking a common key.
• Workflow Orchestrator (Ops Orchestration): Coordinates the end-to-end process. It subscribes to events (BookingReceived, CopyValidated, TagAssigned) and maintains the state of each campaign’s readiness. The orchestrator can update a dashboard or chase list for the operations team, indicating which campaigns are missing copy, clearance, or tags. It implements business rules such as sending reminders or alerts if a campaign’s start date is approaching and something is still missing. When all pieces are in place, it triggers final integration steps (e.g., informing Freewheel to activate the campaign with its assigned creative and tracking).
• Ops Dashboard/UI: A simple web interface (or set of reports) for the operations team to view campaign statuses. It highlights any campaigns that require attention (e.g., “Copy missing for Campaign X” or “Tag not yet received for Campaign Y”) so that ops can intervene only when needed, rather than manually checking every item. The dashboard pulls data from the orchestrator or a central store that the orchestrator maintains.

External systems: The logical design interacts with existing systems rather than replacing them. Key external components are: Prisma (MediaOcean/FreeWheel’s buying platform used by agencies), CARIA (Clearcast’s copy instruction system), Stellar (Channel 4’s internal sales booking system, which receives Prisma bookings), Freewheel (the ad server for serving VOD ads and managing campaigns/creatives), Clearcast (for clearance data), and the agencies’ Tag providers (e.g., Flashtalking or Google for tracking tags). The integration platform communicates with these via APIs or file exchanges: Prisma/Stellar via an API or feed for bookings, CARIA via API/export for rotations, Freewheel via API to push creative/tag data, Clearcast via data feed or API for clearance, and tag providers via email or APIs.

Below is a puml component diagram for the logical view, showing the major components and interactions:

Diagram notes: The Booking Service receives new bookings from Prisma (and Stellar) and notifies the Orchestrator. The Copy Service gets copy instructions from CARIA and uses the NLP Engine (if needed) to match them to a campaign (e.g., attaching Prisma PID if missing). It fetches Clearcast clearance data for the clock number and, once validated, sends an event. The Tag Service similarly receives tag info (from an email or tag provider interface), uses NLP to parse and match it, then signals the orchestrator. The Workflow Orchestrator aggregates these events; once everything is ready, it updates Freewheel (e.g., via API calls to create the campaign line item, associate the cleared creative asset by clock number, and set the tracking tag). The operations team accesses an Ops Dashboard (or it could be an extension of existing UIs) to monitor this process.

Process View (Workflow Orchestration)

The process view describes how the system components work together to execute key workflows, focusing on runtime behavior and orchestration. In this architecture, processes are largely event-driven and parallel – meaning the system reacts to inputs (bookings, copy, tags) and coordinates them asynchronously to achieve an end goal (campaign ready to air). The Operations Team’s workflow is thus managed by the system’s automated processes, with minimal manual steps.

Key characteristics of the process view:

• The Workflow Orchestrator acts as an event hub and state machine: when a new campaign booking arrives, it creates a pending campaign entry and waits for related events. It can spawn parallel subprocesses (or simply await inputs) for copy and tag.
• Parallelism and timing: Upon BookingReceived, the orchestrator can initiate concurrent actions – e.g., notifying the Copy Service and Tag Service of the new campaign. The Copy and Tag services can proceed in parallel (one fetching copy info, the other fetching tag) without waiting on each other. This parallel orchestration shortens the end-to-end turnaround (important given the volume of campaigns).
• Automated decision points: The orchestrator contains logic such as: “If copy not received within X days of start, escalate” or “If CARIA data lacks a PID, attempt auto-match via NLP, else notify ops.” These decision rules ensure that common issues (like missing linkage or late creatives) are handled proactively.
• Event flow: The integration uses events to decouple steps. For example, when the Copy Service finishes processing a new creative, it doesn’t call Freewheel directly; instead, it emits CopyValidated. The orchestrator, upon receiving this event, knows one more piece of the puzzle is done. This decoupling makes it easier to adjust the process flow (e.g., insert a content QC step if needed) without breaking direct call dependencies.

Below is a sequence diagram (puml) illustrating the orchestration for a generic campaign workflow. It shows how the system processes run and interact when a new campaign is set up, emphasizing the parallel handling of copy and tag sub-processes and eventual convergence:

Process explanation: When the Media Agency books a campaign, the Booking Service notifies the Orchestrator. The Orchestrator in parallel calls on the Copy and Tag services to gather their parts. The Copy Service gets the CARIA rotation (if the media agency already created the dummy booking and the creative agency input the copy) or chases it if not present. It uses fuzzy matching if needed to link the CARIA entry to the Prisma PID. It also automatically checks Clearcast for the ad’s clearance (replacing the manual Freewheel input of clearance data). The Tag Service waits for or retrieves the tracking tag, parsing any free-form input (e.g., email text) using NLP to find the tag code. Both services report back, and the Orchestrator then either finalizes the campaign in Freewheel (if all good) or flags it for manual attention (e.g., if copy is not found or tag missing by a cutoff). The operations team thus only needs to look at the Ops UI when there’s an alert (e.g., “Copy missing – contact agency”) instead of manually checking every item. This workflow automation addresses the main pain points: ensuring the Prisma PID and CARIA entries link up, populating tags and clearance without emails and copy-paste, and giving a single view of campaign readiness.

Development View (Implementation)

The development view describes how the solution is realized in terms of software structure, frameworks, and technologies. This integrated system is envisaged as a cloud-based Python application, decomposed into services aligning with the domain contexts. Key points of the implementation include:

• Language & Frameworks: Python is chosen for its rich ecosystem in both web integration (APIs, scripting) and machine learning/NLP. Each service (BookingSvc, CopySvc, TagSvc, Orchestrator) could be implemented as a Python microservice (e.g., using Flask/FastAPI for APIs, or simply as AWS Lambda functions for event-driven pieces). Python’s NLP libraries (such as spaCy or transformers) are used in the NLP Matching Engine to compute text embeddings for campaign names/IDs, enabling fuzzy matching. For simpler cases, libraries like FuzzyWuzzy (Levenshtein matching) can be used to compare strings (e.g., to match “CocaCola UK” vs “Coke UK Campaign” between systems).
• Modules and Code Organization: Each bounded context’s logic resides in its own module or service repository. For example, a campaign_service module encapsulates booking ingestion logic and domain objects for Campaign; a copy_service module deals with CARIA API integration, etc. Domain logic (like validating a Copy or linking a Tag) is implemented within these services following DDD principles (e.g., as domain services or event handlers). Shared utilities (such as the NLP matching functions or a common event bus client) are factored into a shared library.
• APIs and Integration: The system exposes/consumes APIs where needed. It likely uses REST or messaging to integrate. For instance, the Booking Service may expose a webhook endpoint for Prisma/Stellar to call when a new booking is created, or it could poll a feed periodically. The Copy Service might connect to CARIA via a SOAP/REST API or consume a daily export file – this logic would be encapsulated in a gateway class in the copy_service module. The Tag Service could use an IMAP client to read a mailbox or provide a simple web form for the tag team to submit tag data (the form input then processed by the service). All external interactions (with Prisma, CARIA, etc.) are isolated in integration adapter classes, making them easily replaceable if those external APIs change.
• Cloud and Tools: The choice of cloud (e.g., AWS, Azure, GCP) will influence the development specifics. For example, on AWS the team might use AWS Lambda for event-driven functions (triggered by API Gateway or SQS/SNS events), or use AWS Fargate/ECS to run persistent microservices. An event bus like AWS SNS or EventBridge can be used to pass events (BookingReceived, etc.) between services, which in code would be simply producing and consuming messages. The system would also utilize a database (e.g., AWS DynamoDB or RDS) or in-memory store to keep track of campaign state for the orchestrator and for the dashboard. Python’s compatibility with these cloud services (via boto3, etc.) makes it straightforward to implement.
• CI/CD and Infrastructure as Code: Given the need to integrate with multiple systems and iterate quickly, the development process would include automated testing (e.g., simulating fuzzy match scenarios), and continuous deployment for the microservices. Infrastructure could be managed with tools like Terraform or AWS CloudFormation, treating each component (service, queue, database, etc.) as code.

In summary, the development view centers on a Python-based microservices architecture deployed to cloud, leveraging Python’s strengths in integration and NLP. This ensures the team (operations or IT developers) can easily maintain the fuzzy matching algorithms and integration logic in a high-level language, while scaling on cloud infrastructure to handle the volume (\~2600 campaigns/month) and bursty nature of the workload.

(The diagram below gives a high-level illustration of the development structure, with each context as a separate Python service and showing key technologies/platforms used.)

In this development diagram, all custom components are implemented in Python (with appropriate libraries/frameworks noted). The Ops Dashboard might be a lightweight web app (e.g., a React front-end or even just a simple console) that queries the Campaign Status DB or Orchestrator service. The external systems are accessed via their APIs or endpoints. The event bus and database are part of the cloud environment supporting the microservices.

Physical View (Deployment)

The physical view shows how the solution is deployed on infrastructure, including nodes, networks, and external interfaces. The system is designed to be cloud-native for scalability and ease of integration with external APIs:

• Cloud Platform: The solution can be deployed on a cloud provider such as AWS. All integration services (BookingSvc, CopySvc, TagSvc, Orchestrator, NLP engine) run in the cloud – for example, as containerized services on AWS ECS/EKS or as serverless functions (AWS Lambda) triggered by events. The Ops Dashboard could be hosted as a web app (e.g., in S3/CloudFront if static, or as a small web server). The cloud environment provides connectivity to external systems (internet access to Prisma, CARIA, etc.) and secure networking for internal components.
• Networking and Security: Each external integration would use secure channels (e.g., Prisma API keys, CARIA credentials handled securely). The services might reside in a VPC with outbound internet access for calling external APIs, and inbound access restricted (e.g., only API Gateway endpoints for known sources like Prisma or the Ops team). Data at rest (campaign state DB) and in transit are encrypted.
• Physical Nodes/Containers: If using containers, there might be a cluster of nodes (e.g., EC2 instances in an ECS cluster) that run the microservice containers. If using serverless, the “nodes” are abstracted by the platform. Either way, the deployment is distributed: each context service can scale independently based on load (e.g., Copy Service might scale up during certain hours when agencies upload many instructions).
• Integration with Channel 4 systems: Stellar (the sales system) likely runs on-premise or as a managed service; Prisma sends data into it. Our cloud services would receive that data possibly via a secure file drop or API call. For Freewheel, since it’s a SaaS ad-server, the Orchestrator will communicate with Freewheel’s APIs over the internet. Clearcast data (CARIA and clearance DB) are also accessed over secure internet APIs.
• Monitoring & Resilience: Physically, the system includes logging and monitoring components (not shown in diagram) – e.g., CloudWatch for AWS logs, alarms if a process fails to match a CARIA entry, etc. There might also be a fallback: if the NLP matching cannot confidently link a CARIA copy to a Prisma booking, it flags ops to manually confirm via the dashboard (ensuring no campaign falls through the cracks).

Below is a deployment diagram illustrating the physical setup in AWS and how external actors interact with it:

520.

Web server is returning an unknown error Error code 520

Visit cloudflare.com for more information.

2025-08-13 11:03:58 UTC

You

Browser

Working

London

Cloudflare

Working

www.plantuml.com

Host

Error

What happened?

There is an unknown connection issue between Cloudflare and the origin web server. As a result, the web page can not be displayed.

What can I do?

If you are a visitor of this website:

Please try again in a few minutes.

If you are the owner of this website:

There is an issue between Cloudflare's cache and your origin web server. Cloudflare monitors for these errors and automatically investigates the cause. To help support the investigation, you can pull the corresponding error log from your web server and submit it our support team. Please include the Ray ID (which is at the bottom of this error page). Additional troubleshooting resources.

Cloudflare Ray ID: 96e7ba8a3f5563ad • Your IP: Click to reveal 80.229.6.120 • Performance & security by Cloudflare

In this physical view diagram, the microservices are deployed to an AWS compute environment (either containers or functions). The EventBus (SNS or similar) connects services asynchronously. External actors (agencies, tag team) interact via their systems: the Media Agency booking triggers Prisma which calls our BookingSvc; the Creative Agency uses CARIA which our CopySvc polls or receives from; the Tag Team might have an interface to send tags. The Channel 4 Ops Team accesses the system via the Ops Dashboard (over a secure web connection). The Freewheel ad server is an external system the orchestrator calls when finalizing campaigns. This deployment ensures that while components are decoupled, they communicate reliably and scale as needed.

Scenarios (4+1: Implementation Scenarios)

To illustrate the architecture in action, we consider three key business workflows and how the system handles them. Each scenario corresponds to a critical use-case for the operations team: New Campaign Setup, Copy Validation, and Tag Verification. The scenarios demonstrate how the components collaborate, and how manual steps are minimized.

1. New Campaign Setup (Booking to Air)

Goal: A new advertising campaign is booked and all necessary data (copy instructions, clearance, tags) are gathered so the campaign can start on time. This scenario begins with a media agency booking in Prisma and ends with the campaign ready in Freewheel.

Steps (happy path):

1. Booking Entry: The media agency enters a new campaign in Prisma (or CARIA). Prisma automatically sends the booking to Channel 4’s Stellar system. Our Booking Service captures this event (either via direct integration with Prisma’s API or via Stellar). It creates a new Campaign in the system with the given PID and details, and emits a BookingReceived event.
2. Campaign Orchestration: The Orchestrator receives BookingReceived. It creates an entry in the campaign status (with a checklist: “Copy: pending, Tag: pending, Clearance: pending”) and notifies the Copy and Tag services to start processing for this campaign. If Prisma provided a reference to a CARIA booking (the “dummy booking”), that is passed along; if not, the Orchestrator or Copy Service may attempt to create or request one via CARIA’s API. (In the improved process, we aim to automate attaching the Prisma PID to CARIA, addressing the previous inconsistency.)
3. Copy Instruction Linking: The creative agency, seeing the campaign in CARIA (possibly a dummy booking created by the media agency or automatically), inputs the Copy Rotation Instruction with the ad’s clock number. The Copy Service retrieves this instruction (it may poll CARIA or get a push when the instruction is entered). It finds the matching campaign: ideally by a common key (e.g., the CARIA entry contains the Prisma PID or campaign name). If the Prisma PID wasn’t attached, the service uses the NLP Engine to compare the CARIA campaign name/advertiser with existing campaign records, finding the correct Campaign via fuzzy match. It then attaches the PID, effectively linking the CARIA instruction to the campaign internally.
4. Clearance & Copy Availability: As soon as the clock number is known from CARIA, the Copy Service checks if this creative already exists in Channel 4’s library (perhaps from a linear TV submission). In many cases, ads that run on linear are also planned for VOD, so the file might be on hand – the system can search by clock number in a content repository. If found, it can skip requesting the file. If not found, it notes that the file will need to be delivered (which usually the creative agency handles via Clearcast’s Library or a delivery service). Regardless, the Copy Service then queries Clearcast to confirm the ad is cleared for VOD. Clearcast’s database, accessible via API, returns the clearance status for that clock number (and perhaps the approved duration, etc.). The service then updates the campaign’s copy status to “Cleared” (or if not cleared, flags an alert). At this point, assuming clearance is confirmed, the Copy Service emits CopyValidated, indicating the campaign has a valid copy ready (or at least identified and cleared).
5. Tag Assignment: In parallel, the media agency’s tracking partner or the internal tag team generates a tracking tag for the campaign (commonly, this happens once the booking is known). Instead of sending it via free-form email (as in the old process), they could use a simple form provided by the system or continue with email which our Tag Service monitors. The Tag Service either receives a structured input (e.g., JSON via an API or a form submission) or parses the incoming email to extract the tag (e.g., a tracking URL). It then associates this tag with the campaign (again using PID or campaign name to match). The service might validate the tag format (e.g., check that the URL domain matches expected tracking provider and that it contains the correct campaign identifier). Once done, it emits TagAssigned.
6. Finalize Campaign: The Orchestrator, now having received both CopyValidated and TagAssigned for the campaign, marks all items as complete. It proceeds to push the campaign to Freewheel: via Freewheel’s API, it creates the campaign line item (with targeting, dates as per booking), attaches the creative asset (the cleared ad copy, which if not already there, is now either automatically ingested from the linear library or awaits a manual upload – the system can alert ops if the file itself is not yet delivered even though the metadata is there), and configures the third-party tracking tag in Freewheel’s campaign settings. The orchestrator then marks the campaign status as “Ready” in the Ops Dashboard.
7. Go Live: At the scheduled start date, Freewheel will start serving the ad because all prerequisites were handled in advance. The operations team did not need to manually intervene in this happy path; they would simply see the campaign move to Ready status on the dashboard. The system handled the formerly manual “chase list” steps: linking Prisma to CARIA, collecting the tag, inputting clearance info, etc. The ops team’s role becomes one of monitoring and only exception handling.

(If at any step something was missing – e.g., the creative agency did not supply the copy instruction by a certain time – the system would flag the campaign as “Copy Missing” on the dashboard, and possibly send an automated email to the agency reminding them. Similarly, if the tag wasn’t received, it would flag “Tag Missing”. This way, the ops team’s intervention is driven by system alerts rather than by manual discovery.)

Diagram – New Campaign Setup: The sequence diagram in the Process View section above already illustrates this end-to-end flow (from booking to Freewheel). It highlights how the integration orchestrates parallel streams for copy and tag, converging to finalize the campaign. The net effect is that the operations team is presented with a campaign that is either ready or clearly showing which piece is outstanding, instead of having to piece together information from Prisma, CARIA, emails, and spreadsheets.

2. Copy Validation Scenario

Goal: Ensure that the advertisement copy (video file) for a campaign is delivered, cleared, and correctly linked to the campaign booking. This scenario zooms into the copy chasing and validation process, which in the past was a major manual effort for ops.

Context: A campaign booking exists (from linear or VOD booking). The creative asset needs to be obtained and validated. Often, the same ad runs on linear TV, so the asset might already be with Channel 4, but the VOD team might not know that without a link. Clearcast clearance is mandatory for both linear and VOD, but while linear workflows handle it, VOD ops had to manually input clearance into Freewheel. Also, sometimes agencies deliver the file at the last minute, causing delays.

Workflow:

1. Copy Notification: The Copy Integration Service gets a notification of a needed ad copy, either via CARIA (when a creative agency enters a rotation instruction) or via an internal trigger (e.g., a campaign is 2 weeks from start and still no copy identified).
2. Linear Library Check: The service uses the clock number (if available) or the provisional title to search in the Channel 4 linear content library. If it finds a match (exact clock number match), it concludes that the file is already in-house. It can then automatically ingest or transcode it for VOD (or simply mark it as ready for linking in Freewheel). This eliminates duplicate work – previously, the ops team might chase the agency for a file that they actually already had via linear delivery. Now the system leverages that connection.
3. Clearance Verification: Whether or not the file is on hand, the system checks Clearcast clearance: using the clock number, it queries Clearcast’s clearance system. Suppose the creative was cleared for TV; Clearcast might mark it as “Approved for All Platforms” (or some clearance category). If clearance is not found or is “rejected/pending”, the system flags this. (At this point, ops might need to follow up with the agency or Clearcast if clearance is an issue, since the ad can’t run without it.) Assuming clearance is confirmed, the system records the clearance status and perhaps pulls the rating/ restrictions info if needed (e.g., any time-of-day restrictions from Clearcast could be automatically applied to the campaign’s metadata).
4. Copy Ingest (if needed): If the ad file was not already available, the creative agency will deliver it (often via Clearcast’s Library or a service like Peach). The ops team traditionally would get an email or call when the file arrives. In the new system, we could integrate an API or webhook from the content delivery (if available) to notify that the file has been delivered. Alternatively, the ops team might still handle the physical media ingest but once they place the file or mark it received, they update the system (or the system detects the presence of the file in a watchfolder). In either case, the integration platform can be aware when the file is ready.
5. CopyValidated Event: Once the system has (a) a known clock number linked to the campaign, (b) a cleared status from Clearcast, and (c) confirmation that the file is available (either via auto-link from linear or new delivery), it emits CopyValidated for that campaign. This event triggers any waiting processes (the orchestrator will then proceed if tag is also ready). The campaign status is updated to reflect “Copy: ✅”.
6. Exception Handling: If the campaign’s start date is, say, 2 days away and CopyValidated has not occurred, the orchestrator will escalate. It might send an alert to the ops team: “Copy for Campaign X is still missing/uncleared.” The ops person can then manually intervene – call the agency or check what’s wrong (maybe the agency uploaded to the wrong Clearcast entry, etc.). The system thus ensures no campaign is forgotten, addressing the risk of missed start dates due to lack of copy.

Result: The copy validation scenario shows how the operations team’s manual tasks are minimized: linking existing assets is automated, clearance data entry to Freewheel is eliminated (the system directly uses Clearcast’s info), and chasing emails is reduced thanks to automated reminders. Ops can trust that if a campaign is marked “Copy ✅” on the dashboard, all clearance and file issues are sorted. They only act when a warning is raised.

(This scenario primarily involves the Copy Service, Clearcast, and the Orchestrator. It aligns with the Copy Management bounded context and demonstrates the removal of manual “copy chasing” efforts.)

3. Tag Verification Scenario

Goal: Ensure that each campaign has the correct third-party tracking tag applied, and reduce the manual handling of tags. This scenario addresses the issue of tags being emailed and manually input, which is both time-consuming and prone to error.

Workflow:

1. Tag Generation: When the campaign is booked, the media agency’s ad operations (or a third-party like an attribution vendor) generates a tracking tag (a snippet or URL that allows them to track impressions of the ad). In the current process, this tag is often sent via email to the broadcaster’s ops team. In our new system, we have given the agency two possible improved paths: (a) Tag Portal – a small web interface where they can log in and paste the tag for the campaign (ensuring it’s directly captured in the database), or (b) continue via email but the system will parse it. For flexibility, let’s say initially they still use email.
2. Email Parsing: The Tag Integration Service monitors a dedicated email inbox (or listens for incoming messages via a service hook). It uses NLP techniques to parse the email content. For example, the email might say “Tag for Campaign 12345 (Brand X - Summer Promo): https://tracking.example.com/pixel?camp=12345&...”. The service will extract the URL and any identifiers. Using either the campaign PID or name mentioned, it matches this tag to the internal Campaign record. (If it’s not obvious, the service could consult the NLP engine which might parse “Brand X Summer Promo” and match it to “Brand X Summer Promotion” in the campaign data – a fuzzy text match.)
3. Validation of Tag: The service can perform basic validation on the tag – e.g., check that the domain is one of the expected tracking providers (DoubleClick, Flashtalking, etc.), or even send a test HTTP request to ensure the tag endpoint responds (optional). If the tag looks suspicious or mismatched (e.g., campaign name doesn’t match), it could flag ops to review. In most cases, the tag is straightforward.
4. Assign Tag to Campaign: The Tag Service then updates the Campaign’s record with the tag details. It emits a TagAssigned event. Additionally, it could directly call Freewheel’s API to insert the tag (Freewheel allows third-party impression trackers to be attached to a campaign line item). Automating this means the ops team no longer has to copy-paste the tag into Freewheel manually.
5. Ops Visibility: The dashboard now shows “Tag” for the campaign. If for some reason no tag arrived by a cutoff time, the system would flag “Tag Missing” and possibly send an email to the agency reminding them. This proactive approach ensures tags are not forgotten (which could lead to incomplete reporting for the client if not in place).
6. Completing the Loop: Once the campaign goes live, the system could even monitor delivery logs to ensure the tag is firing (this is beyond the immediate scope, but a nice extension – to verify that the impressions are being tracked, the system might check that the tracker URL was called when test ads were served). If an error is found (e.g., wrong tag URL that never fires), ops can be alerted to correct it quickly.

Result: The tag verification process is now streamlined and reliable. The specialist tag team has a clear way to provide tags (and could even skip emailing altogether by using the portal, which further reduces parsing uncertainty). The ops team no longer spends time copying tags into the system or double-checking if the right tag was used – the system ensures the tag is linked to the correct campaign using contextual data. This scenario closes the loop on the “non-revenue” but important task of campaign monitoring setup, freeing ops to focus on more value-added tasks (like optimizing campaign delivery rather than data entry).

---

Conclusion: By applying DDD to separate concerns (campaign data, copy handling, tag handling) and by utilizing a 4+1 architectural approach, the proposed system addresses the main challenges identified in Channel 4’s VOD operations. It maintains existing systems of record (Prisma, CARIA, Freewheel) but glues them together with an intelligent integration layer. Through NLP-driven fuzzy matching and automation, it eliminates inconsistent manual workflows – for example, ensuring Prisma IDs and CARIA rotations are aligned automatically, synchronizing metadata across systems, reusing linear copy assets, and capturing tags without email spreadsheets. The operations team, as the key stakeholder, gains a single-pane-of-glass view of campaign readiness and only intervenes on exceptions, rather than laboriously chasing each item. This not only saves time but also improves accuracy and speed: campaigns are less likely to miss their start dates due to setup issues, protecting revenue and client trust.

Ultimately, this integration and architecture empower Channel 4 to handle the growing volume of VOD campaigns efficiently, allowing the business to scale and pivot from linear to digital without the previous friction. The combination of DDD modeling and the 4+1 views provided ensures that both the business perspective (through scenarios and domain language) and the technical perspective (through architecture and design patterns) are aligned to deliver a robust solution.

Sources:

• Channel 4 VOD Traffic Operations – Process description and challenges
• Clearcast CARIA overview – Linking copy rotations to media bookings
• (Additional internal knowledge of ad tech systems and Domain-Driven Design principles)

Ports and Adapters (Scaffolding)

Below is a complete specification of the polymorphic campaign data model, aggregated from multiple source systems (Prisma, CARIA, Freewheel, manual inputs), and structured using object-oriented programming principles with inheritance and composition.

This includes:

1. Source-specific campaign models (PrismaCampaign, CariaInstruction, etc.)
2. Aggregate unified model using polymorphism.
3. puml class diagram.
4. Ports and Adapters (Hexagonal Architecture) for inputs via APIs, emails, DBs, and human interfaces.

---

1. Polymorphic OOP Data Model

Base Class for All Source Inputs

class BaseCampaignInput:
    def get_campaign_id(self): pass
    def get_advertiser(self): pass
    def get_dates(self): pass
    def get_contact_info(self): pass
    def get_targeting_tactics(self): pass

---

Prisma Booking Input

class PrismaCampaign(BaseCampaignInput):
    campaign_id: str
    advertiser: str
    start_date: date
    end_date: date
    agency: str
    contact_name: str
    pid: str  # Prisma ID

---

CARIA Copy Instruction

class CariaInstruction(BaseCampaignInput):
    campaign_name: str
    clock_number: str
    caria_booking_id: str
    rotation_details: dict
    contact_email: str

---

Freewheel Setup

class FreewheelCampaign(BaseCampaignInput):
    campaign_id: str
    creative_ids: List[str]
    tag_urls: List[str]
    platform: str

---

Manual Entry / Human Input

class ManualEntry(BaseCampaignInput):
    notes: str
    fallback_contacts: List[str]
    updates: dict

---

Aggregated Model

class TargetingTactic:
    name: str
    tag_url: str

class AggregatedCampaign:
    advertiser: str
    campaign_id: str
    start_date: date
    end_date: date
    agency: str
    contact_name: str
    targeting_tactics: List[TargetingTactic]
    sources: List[BaseCampaignInput]

---

2. UML Class Diagram

---

3. Ports and Adapters Architecture

Core Concepts:

• Domain Layer (core logic): Handles AggregatedCampaign, validation, matching, status, etc.
• Adapters (Input/Output): Each source system is wrapped in an adapter that converts to BaseCampaignInput.
• Ports: Interfaces exposed to domain logic; abstract communication with real-world systems.

---

Input Adapters:

Source Type	Adapter Interface	Example Tooling
Prisma API	BookingAPIAdapter	REST Client (Python requests)
CARIA API	CariaAdapter	SOAP/REST Client
Freewheel DB/API	FreewheelAdapter	DB Client or API (SQL/REST)
Email	EmailAdapter	IMAP Client + NLP Parsing/Matching
Manual Input	UIFormAdapter	Web Forms or Admin Panel

---

Output Ports (e.g., for feedback, notifications):

• Ops Dashboard
• Status Webhook
• Alerting/Email
• Freewheel setup API
• Event Bus (SNS/EventBridge)

---

UML for Ports and Adapters

520.

Web server is returning an unknown error Error code 520

Visit cloudflare.com for more information.

2025-08-13 11:03:58 UTC

You

Browser

Working

London

Cloudflare

Working

www.plantuml.com

Host

Error

What happened?

There is an unknown connection issue between Cloudflare and the origin web server. As a result, the web page can not be displayed.

What can I do?

If you are a visitor of this website:

Please try again in a few minutes.

If you are the owner of this website:

There is an issue between Cloudflare's cache and your origin web server. Cloudflare monitors for these errors and automatically investigates the cause. To help support the investigation, you can pull the corresponding error log from your web server and submit it our support team. Please include the Ray ID (which is at the bottom of this error page). Additional troubleshooting resources.

Cloudflare Ray ID: 96e7ba8a385abed2 • Your IP: Click to reveal 80.229.6.120 • Performance & security by Cloudflare