DEV Community

Cover image for Building Multilingual Client Reporting for PPC Agencies: What We Learned Supporting 15 Languages
Jade Chen
Jade Chen

Posted on Edited on

Building Multilingual Client Reporting for PPC Agencies: What We Learned Supporting 15 Languages

#saas #i18n #agencylife #ppcbudgetpacing

Multilingual SaaS sounds straightforward until you try to build it.

At first, the requirement seems simple:

Generate the same PPC report in another language.

Then you start asking questions.

Should CTR be translated?

What happens to campaign names written in Japanese?

Should Google Ads be translated into Chinese?

How do you handle currency?

What about decimal separators?

Dates?

Long German labels that no longer fit inside the report?

And what happens when an agency works internally in English but sends reports to clients in French, Korean and Japanese?

While building multilingual reporting into PaceWise, we discovered that reporting localisation is not really a translation problem.

It is a data architecture and presentation-layer problem.

Here is what we learned while designing a system that can generate PPC client reports in 15 languages.

The First Mistake: Treating the Report as One Block of Text

The simplest implementation would be:

  1. Generate the English report.
  2. Send the whole thing to a translation service.
  3. Return the translated version.

That works surprisingly well for a document containing only paragraphs.

PPC reports are not paragraphs.

They contain structured entities such as:

Campaign
Spend
Budget
CTR
CPC
CPA
ROAS
Conversions
Projected Spend
Remaining Budget
Pacing Status
Enter fullscreen mode Exit fullscreen mode

They also contain values that should never be translated:

$42,315.20
3.82%
Google Ads
Brand_Search_AU
184 conversions
Enter fullscreen mode Exit fullscreen mode

Once we separated the report into structured data and display strings, the architecture became much cleaner.

Instead of translating an entire report, we started thinking in terms of:

data → metric definitions → locale strings → formatted report
Enter fullscreen mode Exit fullscreen mode

That distinction sounds small.

It changes everything.

Separate Data From Presentation

Consider this object:

{
  "campaign": "Brand Search AU",
  "spend": 18342.56,
  "budget": 25000,
  "currency": "AUD",
  "ctr": 0.0412,
  "cpa": 38.74
}
Enter fullscreen mode Exit fullscreen mode

Nothing in that object needs translation.

The data is language-independent.

The presentation layer decides whether the user sees:

Spend
Budget
Click-through rate
Cost per acquisition
Enter fullscreen mode Exit fullscreen mode

or:

費用
予算
クリック率
コンバージョン単価
Enter fullscreen mode Exit fullscreen mode

The underlying numbers remain identical.

This became our core localisation principle:

Never store translated business meaning inside the data layer when it belongs in the presentation layer.

It also makes QA far easier.

If the French report and Japanese report show different spend numbers, that is a data problem.

If they show the same spend number with different labels, that is a localisation problem.

Those are very different bugs.

Use Stable Metric Keys Internally

Instead of using English display labels as identifiers, we use stable semantic keys.

Conceptually:

{
  "metric.ctr": {
    "en": "Click-through rate (CTR)",
    "fr": "Taux de clics (CTR)",
    "ja": "クリック率 (CTR)",
    "ko": "클릭률 (CTR)"
  }
}
Enter fullscreen mode Exit fullscreen mode

The application never needs to ask:

What does “クリック率” mean?

It already knows the metric is:

metric.ctr
Enter fullscreen mode Exit fullscreen mode

The translated string is only how the metric is displayed.

This becomes increasingly important once a reporting system supports 10, 15 or 20 languages.

Without stable keys, localisation logic starts leaking into business logic.

That becomes difficult to maintain very quickly.

Acronyms Are More Complicated Than They Look

PPC marketers operate in a world of acronyms:

  • CTR
  • CPC
  • CPA
  • CPM
  • CVR
  • ROAS

Our initial assumption was that these could remain exactly the same everywhere.

That was mostly true.

But not completely.

In many markets, professionals commonly use a local-language metric name with the English acronym.

For example, Japanese interfaces often present something similar to:

クリック率 (CTR)
Enter fullscreen mode Exit fullscreen mode

Korean might use:

클릭률 (CTR)
Enter fullscreen mode Exit fullscreen mode

Simplified Chinese:

点击率 (CTR)
Enter fullscreen mode Exit fullscreen mode

This is useful because the local-language label improves readability while the acronym preserves familiarity for experienced marketers.

But some markets use local abbreviations too.

The lesson was simple:

Do not hard-code the assumption that an English PPC acronym is universally preferred.

Instead, let each locale define how the metric should appear.

ROAS Behaves Differently

ROAS is a particularly interesting example.

Even in markets where many advertising metrics are translated, ROAS frequently remains:

ROAS
Enter fullscreen mode Exit fullscreen mode

That makes sense.

It has effectively become a domain term.

Trying to force a translated abbreviation into the interface can make the report less familiar to the person using it.

This is why localisation needs domain context.

A linguistically perfect translation is not necessarily the terminology professionals use.

For PPC software, the question should not be:

What is the dictionary translation?

It should be:

What would a PPC manager naturally expect to see?

Campaign Names Should Usually Stay Untouched

Imagine a client has campaigns named:

Spring Sale
Brand Search
新規顧客獲得
서울_브랜드검색
Remarketing_FR
Enter fullscreen mode Exit fullscreen mode

The reporting engine should not automatically translate those campaign names.

They are identifiers created by the advertiser.

Changing them introduces several problems.

The client may no longer recognise the campaign.

The translated report may not match the advertising platform.

Two campaigns could theoretically translate into the same name.

And internal naming conventions may contain abbreviations that have no meaningful translation.

So we treat campaign names as user-owned data.

If a campaign is called:

Brand_Search_UK
Enter fullscreen mode Exit fullscreen mode

it remains:

Brand_Search_UK
Enter fullscreen mode Exit fullscreen mode

even if the surrounding report is in Japanese.

Platform Names Are Brands, Not Translation Strings

The same applies to advertising platforms.

We do not translate:

Google
Meta
Microsoft
TikTok
Enter fullscreen mode Exit fullscreen mode

The descriptive word around them may change.

For example, Simplified Chinese might display:

Google 广告
Meta 广告
Microsoft 广告
TikTok 广告
Enter fullscreen mode Exit fullscreen mode

Traditional Chinese:

Google 廣告
Meta 廣告
Microsoft 廣告
TikTok 廣告
Enter fullscreen mode Exit fullscreen mode

The brand remains recognisable.

This seems obvious, but it matters when a translation engine is allowed to process an entire report blindly.

Currency and Language Must Be Independent

One of the most important architectural decisions was separating report language from account currency.

Consider an Australian agency managing a Japanese client.

The campaign account might operate in:

JPY
Enter fullscreen mode Exit fullscreen mode

The agency interface might be:

English
Enter fullscreen mode Exit fullscreen mode

The client report might be:

Japanese
Enter fullscreen mode Exit fullscreen mode

Those are three separate settings.

A reporting system should therefore avoid assumptions like:

Japanese language = JPY
Enter fullscreen mode Exit fullscreen mode

A Japanese-language report could easily contain:

AUD
USD
EUR
SGD
Enter fullscreen mode Exit fullscreen mode

depending on the advertising account.

The report should respect the account's actual currency.

This becomes particularly important in multilingual PPC reporting, where an agency may generate reports for clients in several languages without altering the underlying advertising data.

Number Formatting Is Also Localisation

Consider:

1,234.56
Enter fullscreen mode Exit fullscreen mode

That format looks natural to an English-speaking user.

Other locales may expect something closer to:

1.234,56
Enter fullscreen mode Exit fullscreen mode

The same issue applies to percentages, dates and currency positioning.

That means formatting should ideally use locale-aware functions rather than manual string concatenation.

Conceptually:

new Intl.NumberFormat(locale, {
  style: "currency",
  currency: accountCurrency
}).format(value);
Enter fullscreen mode Exit fullscreen mode

The system should know:

language
locale
currency
Enter fullscreen mode Exit fullscreen mode

separately.

Then formatting becomes deterministic.

Dates Have the Same Problem

Imagine a report says:

03/04/2026
Enter fullscreen mode Exit fullscreen mode

What date is that?

To an Australian user it may mean:

3 April 2026
Enter fullscreen mode Exit fullscreen mode

To an American user it may mean:

March 4, 2026
Enter fullscreen mode Exit fullscreen mode

That ambiguity is unnecessary.

Locale-aware reporting lets us display dates naturally while preserving the actual underlying date value.

For international reports, we also prefer formats that reduce ambiguity when practical.

Text Expansion Breaks Interfaces

Translation changes layout.

A short English label may become significantly longer in German.

A compact English UI element such as:

Spend
Enter fullscreen mode Exit fullscreen mode

may translate into a much longer phrase depending on context and language.

That causes problems in:

  • table columns
  • dashboard widgets
  • report headings
  • buttons
  • PDF layouts
  • charts
  • mobile interfaces

This taught us not to build layouts around exact English string lengths.

Flexible width, wrapping and responsive components make multilingual systems far more resilient.

CJK languages create the opposite challenge.

Japanese, Chinese and Korean may use fewer characters while requiring different line-breaking behaviour.

Internationalisation is therefore not just about strings.

It affects UI engineering.

Reports Are Different From Product Interfaces

Another useful distinction is that a product can support multiple reporting languages without translating the entire application.

For example, an agency team may be comfortable using an English SaaS interface.

But its clients may expect reports in:

  • French
  • German
  • Japanese
  • Korean
  • Spanish

That creates three separate language layers:

Application language
Campaign language
Report language
Enter fullscreen mode Exit fullscreen mode

They should not be coupled.

At PaceWise, campaigns can contain content in any language while client reporting is available across 15 languages:

  1. English
  2. French
  3. Spanish
  4. German
  5. Portuguese
  6. Italian
  7. Dutch
  8. Polish
  9. Turkish
  10. Swedish
  11. Simplified Chinese
  12. Traditional Chinese
  13. Indonesian
  14. Japanese
  15. Korean

This separation allows agencies to work in the environment that suits their internal team while presenting client-facing information in the client's preferred language.

White-Label Reporting Adds Another Layer

Agencies do not necessarily want clients to see the technology used to generate a report.

They may want the report to display:

Agency logo
Agency colours
Client name
Reporting period
Account performance
Budget status
Enter fullscreen mode Exit fullscreen mode

rather than the software provider's branding.

That means a multilingual report generator must combine several independent layers:

campaign data
+
budget data
+
agency branding
+
client information
+
locale
+
language strings
+
currency formatting
Enter fullscreen mode Exit fullscreen mode

The more tightly those layers are coupled, the harder the system becomes to maintain.

This is one reason we built reporting as part of a broader PPC budget management software for agencies workflow rather than treating reporting as a completely separate process.

The same trusted campaign data can support both budget monitoring and client communication.

Why Reporting and Budget Pacing Belong Together

Many agencies still maintain these as separate workflows.

One spreadsheet tracks budgets.

Another tool generates reports.

Another dashboard tracks campaign performance.

A reporting system then needs to reconstruct information that the budget-management system has already processed.

That creates duplication.

A more coherent architecture looks like:

Advertising Platforms
        ↓
Data Ingestion
        ↓
Normalisation
        ↓
Budget Pacing
        ↓
Forecasting
        ↓
Reporting Layer
        ↓
Language + Branding + Formatting
Enter fullscreen mode Exit fullscreen mode

The same data should ideally power both operational decisions and client reporting.

For example, if a PPC budget pacing system already knows:

Monthly budget
Current spend
Remaining budget
Projected spend
Pacing percentage
Enter fullscreen mode Exit fullscreen mode

the reporting layer should consume those values rather than calculating them independently.

That reduces opportunities for discrepancies.

Google Ads Is a Good Example of Why Normalisation Matters

Advertising platforms do not expose data in exactly the same way.

Google Ads has its own concepts and API structures.

Meta has another.

Microsoft another.

TikTok another.

Before multilingual reporting even enters the picture, a cross-platform reporting system needs a normalised internal model.

For example:

{
  "platform": "google_ads",
  "account_id": "123",
  "campaign_id": "456",
  "spend": 2534.92,
  "currency": "USD",
  "conversions": 73
}
Enter fullscreen mode Exit fullscreen mode

The presentation layer should not care whether those values originally came from Google Ads or another platform.

This is also why a dedicated Google Ads budget pacing workflow can still fit inside a broader cross-platform model.

Platform-specific ingestion happens first.

Normalisation happens afterward.

Reporting operates on the normalised layer.

AI Helps With Translation, but Context Still Matters

AI has made multilingual reporting much easier to build.

It can help with:

  • translation drafts
  • terminology alternatives
  • tone consistency
  • summary generation
  • grammatical QA
  • detecting untranslated strings

But AI needs constraints.

For example, it should know:

Do not translate Google
Do not translate Meta
Do not translate campaign names
Do not modify numeric values
Preserve CTR where appropriate
Use approved terminology for budget pacing
Enter fullscreen mode Exit fullscreen mode

Without those rules, the same translation model can produce slightly different terminology from one report to another.

That creates a consistency problem.

So our preferred workflow is:

approved terminology
+
structured data
+
AI assistance
+
validation
Enter fullscreen mode Exit fullscreen mode

rather than:

send entire document to AI
+
hope
Enter fullscreen mode Exit fullscreen mode

Build a Terminology Dictionary Early

Once you support several languages, you quickly discover the value of a controlled glossary.

For example:

{
  "projected_spend": {},
  "budget_remaining": {},
  "overspending": {},
  "underpacing": {},
  "billing_cycle": {},
  "rollover_budget": {}
}
Enter fullscreen mode Exit fullscreen mode

Each concept can have approved translations by locale.

This gives you consistency across:

  • reports
  • application UI
  • marketing pages
  • emails
  • help documentation

It also makes future localisation much faster.

Instead of asking a translator or AI system to reinvent the terminology every time, the product has an approved vocabulary.

Don't Translate PPC Terms Without Checking the Platform

One of the best localisation references is often the advertising platform itself.

If Google Ads uses a particular term in Japanese, there is a strong argument for using terminology familiar to Google Ads professionals rather than inventing our own translation.

The same principle applies to:

  • Meta Ads
  • Microsoft Advertising
  • TikTok Ads

Localisation should match the professional environment in which users already operate.

This reduces cognitive friction.

Reporting Localisation Can Become a Competitive Feature

Initially, multilingual reporting can sound like a small convenience feature.

For international agencies, it is more important than that.

Consider an agency headquartered in London that manages clients in:

France
Germany
Japan
South Korea
Spain
Enter fullscreen mode Exit fullscreen mode

The account managers may all work in English.

Requiring them to manually translate client reports every month introduces unnecessary work and additional quality-control risk.

If the reporting layer already knows the client's preferred language, the workflow becomes:

select client
→ generate report
→ choose language
→ apply agency branding
→ export
Enter fullscreen mode Exit fullscreen mode

That is a meaningful operational improvement.

It is one reason we believe multilingual reporting fits naturally into a broader best PPC budget pacing tool architecture rather than existing as an isolated translation feature.

The objective is not simply to translate words.

It is to remove repetitive agency work.

Test With Real Reports, Not Just String Lists

A translation spreadsheet can look perfect.

Then you generate an actual report and discover:

  • headings overlap
  • table columns break
  • percentages wrap
  • Japanese text has strange spacing
  • German labels overflow
  • PDF pagination changes
  • charts lose labels
  • the client name collides with the logo

This is why visual QA matters.

For every new language, we try to think about three levels of testing:

1. Linguistic QA

Does the terminology make sense?

2. Data QA

Are all numbers identical to the source data?

3. Visual QA

Does the final report still look professional?

All three matter.

A grammatically perfect report with the wrong CPA is unacceptable.

A numerically correct report with broken formatting is not client-ready either.

Support Languages Progressively

The same principle we used for international SEO applies here:

Do not assume every language needs equal product depth on day one.

You can introduce:

multilingual reports
Enter fullscreen mode Exit fullscreen mode

before:

fully multilingual application UI
Enter fullscreen mode Exit fullscreen mode

Then observe which languages customers actually use.

If Japanese report generation becomes frequent, perhaps Japanese UI localisation deserves priority.

If German usage grows strongly, localise additional product surfaces there.

Product localisation can therefore be demand-driven rather than speculative.

The Architecture Matters More Than the First Translation

The biggest lesson was that supporting another language is easy.

Supporting the 15th language consistently is the real test.

If each new language requires developers to manually modify business logic, something is wrong.

A scalable system should allow a new locale to primarily involve:

translation strings
terminology mapping
locale formatting
QA
Enter fullscreen mode Exit fullscreen mode

rather than rewriting the reporting engine.

That means the investment is really in architecture.

Once the architecture is correct, additional languages become progressively easier.

The Final Model

Our mental model for multilingual reporting now looks like this:

                    Advertising Platforms
                           ↓
                       Raw Data
                           ↓
                      Normalisation
                           ↓
                Budget + Performance Logic
                           ↓
                    Reporting Dataset
                           ↓
            ┌──────────────┼──────────────┐
            ↓              ↓              ↓
         Language       Branding       Locale
            ↓              ↓              ↓
            └──────────────┼──────────────┘
                           ↓
                 Client-Ready Report
Enter fullscreen mode Exit fullscreen mode

The reporting language is deliberately near the end of the pipeline.

That is the important part.

Language changes how the information is presented.

It should not change what the underlying information means.

Final Thoughts

Multilingual reporting initially looked like a translation feature.

It turned into an exercise in software architecture.

The hardest questions were not:

What is “budget” in Japanese?

They were:

Which parts of a report belong to the data layer?

Which parts belong to the localisation layer?

Which values must never be translated?

Which terminology should follow advertising-platform conventions?

How should currency, locale and language interact?

How do we guarantee that 15 reports in 15 languages still represent exactly the same underlying account?

Once those boundaries are clear, the system becomes much easier to reason about.

And that may be the most important lesson:

Internationalisation becomes scalable when language is treated as a presentation concern rather than something embedded throughout the application.

For PPC agencies, that architecture can turn multilingual client reporting from a manual monthly task into a repeatable product workflow.

About the Project

PaceWise is an AI-powered PPC budget pacing and management platform for agencies, in-house performance teams and paid-media professionals.

It brings Google Ads, Meta Ads, Microsoft Advertising and TikTok into one budget-management environment, combining pacing, forecasting, alerts and one-click white-label client reporting in 15 languages.

Top comments (0)