Arabic and English Creative Operations: Managing Bilingual Campaign Complexity
Running campaigns in two languages is a version-control problem before it is a creative one. How to name, version, map and verify bilingual assets — and where linguistic approval ends and operational QA begins.
A bilingual campaign is usually discussed as a translation question. Operationally it is a version-control question, and the two have almost nothing to do with each other.
Whether the Arabic copy reads well is a judgement for whoever owns the brand voice in that market. Whether the approved Arabic file is the one that actually went live, in the right market, on the right placement, pointing at the right page with the right tracking, is an execution question — and it is the one that fails more often, because nothing about it is visible in the creative itself.
Bilingual campaigns multiply execution paths
The arithmetic is routinely underestimated, because people count concepts rather than deliverables.
One creative concept becomes two language versions. Each language version is produced in whatever formats the plan requires — static, video, vertical, square. Each format is sized for the placements each platform accepts. If the campaign runs in more than one market, some of those versions vary again by market. If there are audience-specific messages, they vary once more. The result is not two creatives with a translation; it is a set of deliverables large enough that nobody holds it in their head.
The number depends entirely on the plan, and there is no useful multiplier to publish — an agency's own count from one real campaign is worth more than any rule of thumb. The operational point is that the count is a product rather than a sum, and every item in it needs a name, an approval state and a destination.
Right-to-left layouts deserve one note. An Arabic execution is not a mirrored version of the English one: type, line length and composition change, which means the asset is built rather than flipped. For operations that matters because it produces a genuinely separate file with its own specification check, not a variant that can be assumed correct because its English counterpart passed.
Separate language approval from operational QA
This is the distinction the rest of the article rests on, and getting it wrong in either direction causes problems.
Linguistic approval answers whether the copy is correct, idiomatic and appropriate for the market. It covers translation quality, tone, cultural fit and brand voice, and belongs to the client, the agency, or the linguistic reviewer they appoint. It is a judgement about meaning, and requires someone who owns that meaning.
Operational QA answers whether the approved asset was executed correctly. It verifies that the file in the ad is the approved version rather than a draft or a superseded one; that it sits in the right campaign; targeted at the right market; on a placement it was built for; pointing at the correct landing page; carrying the correct tracking; and that what is live matches what was signed off.
Neither substitutes for the other. An execution partner should not be assessing Arabic grammar, translation accuracy or cultural appropriateness — that is not an operational check and claiming it would misrepresent what the verification actually covers. Equally, a linguistic reviewer approving copy in a document has not confirmed that the right file reached the right placement. Campaigns go wrong when each party assumes the other covered the gap.
Build an asset naming system humans can read
Naming is the cheapest control available and the one most often left to whoever exports the file. The test is simple: can someone who was not in the creative process tell, from the filename alone, what this asset is and whether it is the current one?
The dimensions usually worth encoding are market, language, format, platform, campaign or concept, version, and approval status. Not all of them belong in every name — a convention carrying nine fields stops being readable, which defeats the purpose.
An illustrative pattern, offered as an example rather than a required convention: market, then language, then concept, then format and size, then version — so a reader can scan left to right from the broadest dimension to the narrowest. Whatever the agency chooses, the properties that matter are that it is applied identically by everyone, that language and version are both visible, and that it survives being read in a platform interface where the name may be truncated.
Control versions before trafficking
The risk in bilingual work is not a missing asset. It is several assets with almost the same name, where only one is approved and the difference is a suffix.
A small set of explicit states is usually enough: draft, in review, approved, superseded and final. What makes them work is that they are recorded somewhere a trafficker can see at the moment of build, rather than inferred from a folder date or a message thread. An asset that has been replaced should be identifiable as replaced — moved, renamed or marked — because the most common version failure is not using the wrong file knowingly; it is using a file that was correct last week.
Where two languages are in play this compounds, because the versions rarely move in step. English copy is often approved first while the Arabic version is still in review, which means a campaign can be half-approved for days. Treating approval as a per-asset state rather than a per-campaign milestone is what keeps that visible.
Map every approved asset to its destination
An approved asset with no stated destination is an open question that someone will answer from memory at build time.
The mapping worth maintaining connects each creative to the campaign it belongs to, the ad group, ad set or line item within it where applicable, the market, the language, the placement or format it was built for, and the landing page it should point to. On a single-language, single-market campaign this is obvious enough to be implicit. Across two languages and several markets it is the document that prevents the most expensive category of error.
That category is worth naming: the mismatched pairing. The Arabic creative in the English ad set. The UAE version live in Saudi Arabia. The correct asset on a placement whose dimensions it was not built for. Each is individually trivial and none of them is visible in the asset itself — only in the relationship between the asset and where it ended up.
URLs and tracking are part of creative operations
A creative is not finished when the visual is approved. It is finished when the visual, the destination and the measurement attached to it are all correct together.
In bilingual work the landing page is itself a language variant, which makes the pairing a real decision rather than a default: an Arabic ad reaching an English page is a complete execution even though every individual component passed its own check. The same applies to tracking parameters — a UTM structure that identifies campaign and source but not language or market produces reporting in which the two versions are indistinguishable, and any question about how they performed becomes unanswerable after the fact.
What has to be true before launch is that the landing URL is final and resolving, that it is the correct language variant for the ad, that tracking parameters are present and correctly formed, and that the conversion the campaign optimises toward is the one the KPI depends on. How that signal layer is implemented and validated is set out under measurement and analytics.
QA bilingual campaigns in layers
A structured operation separates validation into distinct points — input QA on the brief and assets, creative QA against specification, build QA on the campaign as configured, launch QA once delivery starts, and ongoing QA in flight. Bilingual work does not add a layer; it doubles what several of the existing layers have to cover.
Creative QA against specification is the layer most affected: file weight, dimensions, duration, safe areas and tag behaviour all have to pass for every language version independently, because an Arabic build is a separate file rather than a derived one. Build QA acquires the pairing checks described above. Launch QA has to confirm that both language versions are actually serving, which is a different question from whether both were uploaded.
What a thorough pre-launch and post-launch pass covers is set out in the campaign launch QA checklist. Nothing in it is language-specific, and that is the point: the operational checks are the same in both languages, applied twice, at the same depth. The checks that vary by language are linguistic, and they sit with a different owner. Where creative is produced and audited against platform and publisher specification, that work is described under creative and adtech.
Approval status needs to remain visible
Most approval breakdowns are not disputes. They are ambiguity: nobody can say with certainty who approved which version, or when.
The practices that prevent it are unglamorous and entirely manual if they need to be. Record who approved each asset and which version — a name against a version, not a general sign-off on the campaign. Keep the approval state attached to the asset rather than held in a conversation. When an asset is replaced, mark the old one superseded rather than deleting it, so a question about week one can still be answered in week six.
None of this requires a system. It requires a shared, current record that whoever is trafficking can read without asking. An agency with a clear spreadsheet that everyone updates is in better shape than one with sophisticated tooling that nobody maintains.
Reporting needs consistent creative identifiers
The naming decision made at the start determines what can be asked at the end. If creative names do not carry language and market, a report can show which ads delivered without being able to show how the two language versions compared.
Consistent identifiers connect creative delivery back to campaign, market, language and version. Without them, answering a reasonable client question — which version performed better, in which market — means reconstructing the mapping by hand, every time, from whatever the platform export happens to carry.
One caution about interpretation. Differences between language versions can come from creative, audience, placement, timing, budget allocation or landing-page experience, and a reporting view that attributes them to language alone is drawing a conclusion the data does not support. Identifiers make the comparison possible; they do not make it causal.
A practical bilingual creative handoff checklist
Questions worth answering at handoff, before anything is trafficked:
- Is every asset named to a convention that shows language, market and version?
- Is it clear which version of each asset is the approved one?
- Are superseded versions marked or removed so they cannot be picked up by mistake?
- Is linguistic approval complete for every language, and recorded against a named person?
- Is it clear that linguistic approval and operational verification are separate sign-offs?
- Does every approved asset have a stated destination — campaign, market, placement?
- Is each asset built to the specification of the placement it is mapped to?
- Is the landing page final, resolving, and the correct language variant for the ad?
- Do tracking parameters identify language and market, not only campaign and source?
- Is the conversion event the ad optimises toward the one the KPI depends on?
- Are both language versions complete, or is one still pending?
- Is it known who may approve a replacement asset after launch?
- Will creative identifiers in reporting let language and market be distinguished afterwards?
Bilingual campaigns are not harder to execute than single-language ones in any individual step. They are harder because every control that was implicit becomes load-bearing: a naming convention that was a convenience becomes the only way to tell two files apart, and an approval that was understood becomes something that has to be written down. The work is to make those controls explicit before the volume arrives, not after a version goes live in the wrong market.
Trafficomm supports agencies with the execution layer around assets the agency and its client have approved — creative auditing against platform and publisher specification, trafficking, campaign build, QA, measurement setup and documentation — working inside the naming conventions and processes the agency already uses. Copy, translation and linguistic approval stay with the agency and its client. How multi-market programmes coordinate around this is set out in GCC multi-market campaign operations; the execution functions themselves under ad operations.
From the operations team
Want to see how this applies to your team?
Request an operations assessment — we'll review your workflow, volumes and platforms.
Request an Operations AssessmentKeep reading
Related insights
GCC Multi-Market Campaign Operations: A Practical Guide for Agencies
Running one campaign across several Gulf markets is not a copy-and-change exercise. What to standardise, what genuinely has to differ by market, and how to keep structure, measurement, QA and reporting readable once a programme crosses borders.
ReadThe Agency Campaign Launch QA Checklist
A practical pre-launch and post-launch QA checklist for digital advertising campaigns — covering brief, structure, budget, targeting, placements, creative, tracking, final review and launch verification.
ReadSaudi Digital Advertising Outlook 2027: What Agency Operations Teams Should Prepare For
Saudi campaigns are getting operationally heavier, not just larger — more platforms, more creative versions, tighter launch windows and measurement that has to hold. What agency operations teams should settle before 2027.
ReadLet's talk operations
Talk to the operators behind the Performance Lab.
Request an operations assessment and we'll map where setup, QA, optimization and reporting time is going — and what a performance operations layer would change.