DEV Community: Jade Chen

How We Built 14 Localised SaaS Landing Pages Without Localising the Entire Product

Jade Chen — Tue, 03 Nov 2026 02:50:25 +0000

How We Built 14 Localised SaaS Landing Pages Without Localising the Entire Product

Internationalising a SaaS product does not have to mean translating the entire application.

That was one of the most useful lessons we learned while expanding PaceWise, a PPC budget pacing and management platform, beyond an English-only marketing site.

We wanted international users to be able to:

discover the product in their own language
understand what it does
see locally relevant examples
evaluate whether it fits their workflow
generate client reports in their preferred language

But we did not want to immediately translate every dashboard, navigation item, settings screen and product workflow.

So instead of treating internationalisation as one enormous project, we separated it into layers.

Our first major step was launching 14 additional localised marketing pages.

This article explains how we structured them, what we deliberately did not localise, and why separating marketing language from application language made the project much more manageable.

The Architecture Started With One Important Decision

The first decision was:

Do we localise the website, or do we localise the entire product?

Those are very different projects.

A full application localisation could involve:

Navigation
Dashboard labels
Settings
Alerts
Error messages
Billing
Onboarding
Reports
Help documentation
Emails
Tooltips
Form validation

Multiply that by 14 languages and the maintenance burden becomes significant very quickly.

Instead, we started with the acquisition layer.

The PaceWise application UI currently remains English.

But our international users can now discover the platform through localised marketing pages, run campaigns regardless of campaign language, and generate client-facing reports in multiple languages.

That separation gave us a much more practical internationalisation roadmap.

The 14 Localised Entry Pages

We currently have dedicated marketing experiences for 14 additional languages and markets.

European markets

Our German-language experience is available through the German PPC budget pacing page.

Spanish-speaking agencies can discover the product through our PPC budget pacing tool Spanish page.

French marketers have a dedicated PPC budget pacing tool French experience.

We also created:

Asia-Pacific markets

We also created:

These are not 14 separate versions of the SaaS application.

They are localised entry points into the same product.

That distinction is important.

We Treated Language and Product Logic Separately

Budget pacing itself is not language-dependent.

At the core, the system still works with concepts such as:

budget
spend to date
remaining budget
billing period
projected spend
pacing status

Those concepts exist whether the user speaks English, French, Spanish, Japanese or Korean.

So the application logic does not need to know that:

Projected Spend

might eventually appear as a different string in another locale.

The underlying concept should remain stable.

A simplified model might look like:

{
  "budget": 50000,
  "spend": 31200,
  "currency": "EUR",
  "projected_spend": 48700,
  "pacing_status": "on_track"
}

The business logic remains unchanged.

Localisation belongs mostly in the presentation layer.

Marketing Language Is Not Application Language

This was one of the most useful architectural distinctions.

A user can currently experience:

French marketing page
English application UI
French client report
French campaign names
EUR advertising account

Those things can coexist perfectly well.

The marketing page needs to help the user understand the product.

The application needs to manage structured advertising data.

The client report needs to communicate results to the client's audience.

They are separate layers.

For us, the model became:

Marketing language
Application language
Campaign language
Reporting language
Documentation language

Each can evolve independently.

Campaign Language Does Not Need to Control the Product

Consider three campaign names:

Brand_Search_UK

Acquisition_Nouveaux_Clients

新規顧客獲得

A PPC budget platform does not necessarily need to understand the semantic meaning of those strings.

It needs structured values such as:

campaign ID
platform
budget
spend
currency
conversions
billing period

That means campaigns can use different languages without requiring the entire PaceWise interface to use those languages.

This is one reason internationalisation becomes much easier when product logic is built around structured data rather than display text.

Language and Currency Must Be Independent

Another implementation lesson was not to couple language and currency.

A French-language user may manage accounts in:

EUR
GBP
USD
CAD
CHF

A Spanish-speaking agency may run campaigns across Spain, Mexico and the United States.

So a configuration such as:

{
  "language": "fr",
  "market": "FR",
  "currency": "EUR"
}

may work for a marketing example.

But the real advertising account currency should still come from the account itself.

For our localised pages, we use locally familiar budget examples where useful.

For example:

€30,000

may feel more natural on a French page.

A Japanese example might use:

¥5,000,000

A Taiwan-focused Traditional Chinese example might use:

NT$1,000,000

But PaceWise subscription pricing can remain in USD.

Those are different concerns.

Search Intent Also Needs Localisation

One of the easiest mistakes is to translate an English SEO keyword literally.

That does not guarantee users in another market actually search that way.

For example, the English

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

Jade Chen — Mon, 02 Nov 2026 08:49:42 +0000

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:

Generate the English report.
Send the whole thing to a translation service.
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

They also contain values that should never be translated:

$42,315.20
3.82%
Google Ads
Brand_Search_AU
184 conversions

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

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
}

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

or:

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

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)"
  }
}

The application never needs to ask:

What does “クリック率” mean?

It already knows the metric is:

metric.ctr

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)

Korean might use:

클릭률 (CTR)

Simplified Chinese:

点击率 (CTR)

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

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

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

it remains:

Brand_Search_UK

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

The descriptive word around them may change.

For example, Simplified Chinese might display:

Google 广告
Meta 广告
Microsoft 广告
TikTok 广告

Traditional Chinese:

Google 廣告
Meta 廣告
Microsoft 廣告
TikTok 廣告

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

The agency interface might be:

English

The client report might be:

Japanese

Those are three separate settings.

A reporting system should therefore avoid assumptions like:

Japanese language = JPY

A Japanese-language report could easily contain:

AUD
USD
EUR
SGD

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

That format looks natural to an English-speaking user.

Other locales may expect something closer to:

1.234,56

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);

The system should know:

language
locale
currency

separately.

Then formatting becomes deterministic.

Dates Have the Same Problem

Imagine a report says:

03/04/2026

What date is that?

To an Australian user it may mean:

3 April 2026

To an American user it may mean:

March 4, 2026

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

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

They should not be coupled.

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

English
French
Spanish
German
Portuguese
Italian
Dutch
Polish
Turkish
Swedish
Simplified Chinese
Traditional Chinese
Indonesian
Japanese
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

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

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

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

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
}

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

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

rather than:

send entire document to AI
+
hope

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": {}
}

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

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

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

before:

fully multilingual application UI

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

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

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.

How We Built International SEO for a SaaS Product Without Creating 100 Duplicate Pages

Jade Chen — Mon, 02 Nov 2026 08:43:03 +0000

International SEO sounds deceptively simple.

Translate your website.

Create a few new URLs.

Add hreflang.

Wait for traffic.

In practice, it gets complicated very quickly.

When we started expanding PaceWise internationally, we had a straightforward product: PPC budget pacing and management software for agencies and performance marketers.

But the international SEO question was much harder:

How do you make a SaaS product discoverable across multiple languages and markets without creating hundreds of thin, repetitive pages?

That challenge becomes even more important for niche SaaS products.

A large ecommerce site can justify thousands of country and language combinations because the underlying catalogue is huge.

A specialist B2B SaaS platform usually cannot.

So instead of translating every page into every language, we built a much leaner international SEO architecture.

This article explains what we learned.

The Obvious Strategy Was Also the Wrong One

Our first theoretical model looked something like this:

English homepage
German homepage
French homepage
Spanish homepage
Japanese homepage
Korean homepage
Chinese homepage

Then repeat the process for:

features
integrations
pricing
agency pages
Google Ads pages
Microsoft Ads pages
TikTok pages
comparison pages
reporting pages
blog content

It does not take long before that becomes hundreds of URLs.

Technically, you can build that structure.

The bigger question is whether you should.

Every additional localised page introduces ongoing work:

translation
keyword research
QA
metadata
internal linking
hreflang
canonicalisation
content updates
product changes
broken links
sitemap maintenance
translation drift

If one product feature changes, the update suddenly needs to propagate across 15 languages.

That is manageable with strong localisation infrastructure.

It is much less attractive when you are still trying to discover which international markets actually have demand.

So we changed the question.

Instead of asking:

How do we translate our entire site?

We asked:

What is the smallest useful international SEO footprint that lets us test demand properly?

That changed the architecture completely.

Start With One Strong Entry Page Per Market

For PaceWise, we started by creating localised entry pages rather than immediately replicating the entire English website.

The underlying principle was simple:

Build enough local-language content for a user and search engine to understand the product, but don't create pages merely because a URL template makes it possible.

For a PPC product, a strong local landing page can already explain:

what PPC budget pacing is
the problem the software solves
which advertising platforms are supported
forecasting
overspend and underpacing alerts
custom billing cycles
client reporting
international reporting capabilities
security and trust
who the product is designed for

That is enough to test whether the market responds.

If a localised page starts generating impressions, clicks, trials or qualified enquiries, we can justify deeper localisation later.

This is much more useful than translating 30 pages into a market where nobody is searching for the product.

International SEO Is Not Translation

One of the biggest lessons was that translation and localisation are different jobs.

Translation asks:

What does this English sentence mean in German?

Localisation asks:

How would a German PPC manager naturally describe this concept?

Those are not always the same answer.

Paid-media terminology is full of awkward examples.

Words such as:

budget pacing
projected spend
overspend
underpacing
conversion rate
cost per acquisition
billing cycle

may have technically correct translations that professionals rarely use.

Sometimes the English acronym remains common.

Sometimes the local-language term is dominant.

Sometimes both appear together.

This is particularly important when your audience is highly technical.

A marketer who spends all day inside Google Ads already has a professional vocabulary.

Your localisation needs to match that vocabulary rather than simply produce grammatically correct text.

Our Core SEO Topic Had to Stay Consistent

One advantage of a niche SaaS product is that the primary search intent is fairly clear.

PaceWise sits around concepts such as:

PPC budget pacing
PPC budget management
paid media forecasting
overspend prevention
multi-account budget control

That topic should remain recognisable regardless of language.

Our English site therefore acts as the semantic foundation.

For example, users researching a PPC budget pacing hub should understand the same underlying product problem as someone arriving through a localised international landing page.

The words may change.

The market examples may change.

But the product entity and search intent should remain consistent.

Keep Your Most Important Commercial Pages Strong

International expansion also made us more disciplined about our English architecture.

Before multiplying content across languages, it helps to identify which pages actually matter commercially.

For us, several pages play distinct roles.

The main site establishes the product category and brand. We position PaceWise as a best PPC budget pacing tool candidate for teams that need stronger control over paid-media budgets.

Then we have pages aimed at specific search intent.

For agencies managing multiple accounts, there is a dedicated PPC budget management software for agencies page.

For platform-specific intent, we have resources such as Google Ads budget pacing and Meta Ads budget pacing pages.

And for users actively evaluating vendors, we created a separate guide covering the Top 5 PPC budget pacing tools for agencies.

Those pages have different jobs.

That distinction matters before localisation.

If every page is trying to rank for the same broad term, translating them into 15 languages simply multiplies your cannibalisation problem.

Use Separate URLs for Different Languages

One decision was relatively straightforward.

Each localised page should have its own crawlable URL.

Google recommends separate URLs for different language versions rather than dynamically changing the page according to browser language or cookies.

That makes sense operationally too.

A structure such as:

example.com/
example.com/de/
example.com/fr/
example.com/es/
example.com/jp/
example.com/kr/

is simple to crawl, monitor and debug.

It also gives you a clear unit of measurement inside Google Search Console.

You can see whether /de/ is receiving German queries.

You can compare indexing and clicks between /jp/ and /fr/.

You can diagnose individual pages without guessing which content Google rendered for which visitor.

Simple URLs are boring.

Boring infrastructure is usually good infrastructure.

Google also recommends clear, logical URL structures for multilingual and multi-regional sites.

https://developers.google.com/search/docs/crawling-indexing/url-structure

Hreflang Is a Mapping System, Not a Ranking Hack

hreflang is one of those international SEO topics that tends to sound more mysterious than it is.

Its job is essentially to tell Google:

These URLs are alternate language or regional versions of the same underlying page.

For example:

<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
<link rel="alternate" hreflang="ja" href="https://example.com/jp/" />
<link rel="alternate" hreflang="ko" href="https://example.com/kr/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

The important implementation detail is reciprocity.

If the German page says the French page is an alternate, the French page needs to identify the German page too.

Google's documentation explicitly notes that missing return links can cause hreflang annotations to be ignored.

Official reference:

https://developers.google.com/search/docs/specialty/international/localized-versions

For us, the useful mental model became:

Every localised landing page belongs to one hreflang cluster.

Once you think of it that way, debugging becomes much easier.

The Canonical Mistake We Wanted to Avoid

A common multilingual SEO mistake is to create translated pages and then canonicalise every one of them back to English.

Conceptually, that says:

This German page is merely a duplicate of the English page.

That defeats much of the purpose of creating a genuine German page.

If the German content is intended to rank independently, it should generally have a self-referencing canonical.

For example:

<link rel="canonical" href="https://example.com/de/" />

Then hreflang connects it to the equivalent English, French, Japanese and other versions.

Canonicalisation and hreflang solve different problems.

One identifies the preferred URL for a piece of content.

The other describes relationships between localised versions.

Mixing those concepts can create confusing international indexing behaviour.

One Page Per Language Does Not Mean One Template With 14 Replacements

This is where the strategy becomes more interesting.

A low-quality internationalisation workflow might take:

PPC budget management software for agencies

and simply replace:

agencies in Australia

with:

agencies in Germany

then:

agencies in France

then:

agencies in Japan

That is not really localisation.

It is find-and-replace SEO.

We wanted each page to have some market relevance.

That can include:

locally natural PPC terminology
local currency examples
market-specific business language
different explanations where terminology varies
culturally natural calls to action
local date and number formatting
country-appropriate trust messaging

But the differences should be useful.

You do not need to invent fake local information just to make pages different.

There is no value in pretending your product has a Berlin office or Tokyo team if it doesn't.

Authenticity matters more than artificial uniqueness.

Currency Is Part of Localisation, But Billing Does Not Need to Be

This was another useful architectural distinction.

Our subscription pricing can remain in USD.

But a local PPC manager should not necessarily see every budget example expressed in USD.

A German agency may naturally think about:

€100,000 monthly media budget

A Japanese team may relate more naturally to:

¥10,000,000

A Taiwanese PPC manager may expect:

NT$1,000,000

Those examples improve comprehension without requiring us to build local subscription billing immediately.

So we separated:

product billing currency

from:

advertising budget display currency

This is a small example of a broader internationalisation principle:

Do not couple things simply because they both look like localisation.

Language, Country and Currency Are Three Different Variables

This sounds obvious until you start coding.

Consider Traditional Chinese.

Language:

Traditional Chinese

Target market:

Taiwan

Locale:

zh-TW

Budget currency:

TWD / NT$

Those variables are related, but they are not interchangeable.

Similarly:

German language
Germany market
de-DE locale
EUR currency

Software architecture becomes easier when each has its own field.

For example:

{
  "language": "zh-Hant",
  "market": "TW",
  "locale": "zh-TW",
  "currency": "TWD"
}

That gives you much more flexibility later.

Don't Force Every Metric Into Translation

Our PPC localisation work exposed another subtle problem.

Metrics like:

CTR
CPC
CPA
ROAS
CVR

do not behave consistently across markets.

In some languages, marketers commonly use the English acronym alongside a translated label.

For example:

クリック率 (CTR)

or:

클릭률 (CTR)

In other markets, local acronyms may be more common.

That means the software should not treat English labels as universal constants.

A better architecture is:

metric key → locale-specific display string

For example:

{
  "metric": "ctr",
  "en": "Click-through rate (CTR)",
  "ja": "クリック率 (CTR)",
  "ko": "클릭률 (CTR)"
}

The metric stays the same.

Only its presentation changes.

This becomes particularly important once you move from website localisation into product UI and reporting.

Localise the Search Intent, Not Just the Copy

This is one of the biggest SEO lessons.

People in different markets may search for the same problem differently.

A direct translation of:

PPC budget pacing software

may not be the phrase with the strongest local search behaviour.

Users may search around:

PPC budget management
advertising budget management
Google Ads budget control
campaign budget tracking
advertising spend forecasting

That means international keyword research should happen after you understand the language, not before.

Machine translation can help generate candidate terms.

It should not be treated as keyword research.

The SERP still matters.

Internal Links Should Help Explain the Product Architecture

Once localised pages exist, another temptation is to link every local page to every product page.

That creates noise quickly.

Instead, internal links should reflect user intent.

Someone researching budget pacing may benefit from a deeper guide.

Someone managing dozens of clients may benefit from the agency page.

Someone primarily working inside Google may need the platform-specific page.

Someone comparing software may want a tools comparison.

This is one reason we maintain distinct resources around the topic rather than putting everything on the homepage.

A clean topic cluster can look something like:

PPC Budget Pacing
│
├── Agency Budget Management
├── Google Ads Budget Pacing
├── Microsoft Ads Budget Pacing
├── TikTok Ads Budget Pacing
├── Multilingual Reporting
└── PPC Budget Pacing Tool Comparisons

The localised pages can then connect users into the relevant parts of that architecture.

Avoid Creating International Doorway Pages

There is an important line between localisation and manufacturing pages purely to capture keywords.

Creating pages like:

PPC software Sydney
PPC software Melbourne
PPC software Brisbane
PPC software Perth

when the product is identical and the company operates entirely online is difficult to justify.

There is usually no meaningful difference for the user.

Language localisation is different because language materially affects usability.

Country localisation can also be legitimate where currency, terminology, regulation, product availability or market expectations differ.

But creating arbitrary geographic variants solely for search coverage is not a scalable strategy.

Google continues to emphasise people-first content rather than producing large quantities of pages primarily to capture search traffic.

https://developers.google.com/search/docs/fundamentals/creating-helpful-content

We Chose Progressive Localisation

The model we eventually settled on looks like this:

Stage 1 — Localised discovery page

Create one strong page.

Measure:

indexing
impressions
queries
ranking positions
clicks
trial starts

Stage 2 — Supporting local content

If demand exists, create deeper content around the problems users actually search for.

Stage 3 — Product localisation

Translate high-value UI components where there is enough product usage to justify it.

Stage 4 — Full market experience

Only the strongest markets receive a much deeper localisation layer.

This prevents localisation from becoming a huge fixed investment before demand has been demonstrated.

Search Console Becomes Market Research

One unexpected benefit of this approach is that SEO becomes a market-validation tool.

Suppose the Japanese page begins appearing for multiple relevant queries.

That tells us something.

If it gets impressions but no clicks, perhaps the title and positioning need work.

If it gets traffic but no trials, perhaps the landing experience is wrong.

If it generates trials, that is stronger evidence that Japanese localisation deserves additional investment.

The same process can be repeated across markets.

Instead of deciding international priorities purely from market-size reports, you can observe real search behaviour.

In other words:

international SEO can become lightweight demand discovery.

Don't Translate Everything at Once

This may be the most important lesson.

SaaS teams often assume that internationalisation requires a massive launch:

We support 15 languages now.

But supporting a language at one layer does not require every layer to change simultaneously.

For example, a product can have:

a localised marketing page
English application UI
campaigns containing any language
client reports generated in 15 languages

Those are separate capabilities.

Over time, you can localise each layer according to customer demand.

That makes international expansion much less risky.

AI Helps, But It Doesn't Own the Final Output

AI has made internationalisation dramatically faster.

We use it for things such as:

first-pass translation
terminology alternatives
metadata drafts
terminology comparisons
UI string QA
spotting untranslated text
formatting consistency

But there is an important difference between:

AI-generated translation

and:

production-ready localisation

The latter still needs context.

A technically correct translation can sound unnatural to a PPC specialist.

A translated keyword may have no search volume.

A metric label may be linguistically correct but inconsistent with Google Ads terminology in that market.

AI is an excellent localisation accelerator.

It is not a substitute for localisation judgement.

The Real Goal Is Not More Pages

International SEO can easily become a page-count exercise.

We tried to avoid that mindset.

The objective is not:

How many localised pages can we publish?

The objective is:

Can someone in another market discover, understand and trust our product?

Sometimes one excellent page can accomplish that better than 30 mediocre translations.

Once demand appears, expansion becomes much easier to justify.

That gives us a simple operating principle:

** Localise progressively, measure aggressively and only deepen markets that show real potential.**

For a specialist SaaS product, that has been far more practical than trying to build 100 translated pages on day one.

About the Project

PaceWise is an AI-powered PPC budget pacing and management platform for agencies, in-house teams and performance marketers managing Google Ads, Meta Ads, Microsoft Advertising and TikTok.

Our internationalisation work currently spans localised marketing experiences, campaigns in different languages and multilingual client reporting, while keeping the underlying budget-management logic consistent across markets.

Why CTR, CPC, CPA and ROAS Don’t Translate the Same Way Everywhere

Jade Chen — Sun, 01 Nov 2026 12:18:55 +0000

When you localise a SaaS product, some words are easy.

“Dashboard” gets translated.

“Settings” gets translated.

“Budget” gets translated.

Then you reach:

CTR

CPC

CPA

CPM

CVR

ROAS

And suddenly the obvious approach stops being obvious.

Should the acronyms stay in English?

Should the full metric names be translated?

Should both appear?

Does a Japanese PPC manager expect to see CTR?

Does a Turkish marketer?

What about Traditional Chinese?

We ran into exactly this problem while localising PaceWise, a PPC budget pacing and management platform, for multiple international markets.

What looked like a translation issue turned out to be a much more interesting product-design problem.

The Initial Assumption: Everyone Uses the English Acronyms

Our starting assumption was simple:

PPC professionals everywhere already know CTR, CPC, CPA and ROAS.

That assumption is mostly correct.

But “mostly correct” is not enough when you are building a multilingual product.

Digital advertising terminology is unusual because much of it developed inside global platforms.

Google Ads, Meta Ads and other advertising systems introduced English terminology that was then adopted internationally.

Terms such as:

CTR
CPC
CPA
CPM
ROAS
ROI
API
SaaS
KPI

often survive translation.

A marketer reading a completely Japanese article may still recognise CTR.

A French PPC report may use ROAS.

A German agency may comfortably discuss CPC.

But once we looked more closely, we found that the behaviour is not universal.

Japanese: Translate the Meaning, Keep CTR

Google's Japanese Ads documentation provides a useful example.

The Japanese term for click-through rate is:

クリック率

But Google also presents the acronym:

クリック率（CTR）

So the reader gets both:

local-language terminology + globally recognised PPC shorthand

This is the pattern we like for a localised SaaS interface.

For example:

クリック率 (CTR)

rather than:

CTR

or only:

クリック率

The first version works for experienced PPC professionals while still making the interface feel genuinely Japanese.

When developing PPC budget pacing in Japanese, this became an important consideration: the product terminology needs to feel familiar to Japanese performance marketers without unnecessarily replacing internationally recognised PPC terminology.

Korean Follows a Similar Pattern

Korean paid-media terminology follows a similar pattern.

The local term for click-through rate is commonly displayed alongside the international abbreviation:

클릭률 (CTR)

This gives marketers both the Korean description and the metric shorthand they already recognise from global advertising platforms.

For a PPC budget pacing software for agencies, that matters because Korean teams may work across multiple markets and platforms.

A Korean marketer might work internally in Korean while sharing spreadsheets, platform screenshots and performance reports containing English PPC abbreviations.

That is one reason we built a dedicated experience for PPC budget pacing in Korean, rather than assuming an English interface and English marketing page would be equally effective for Korean users.

Simplified Chinese Also Retains Familiar PPC Acronyms

Simplified Chinese presents another interesting hybrid.

A metric such as CTR can be displayed as:

点击率 (CTR)

The Chinese terminology explains the meaning, while the acronym retains its connection to the global advertising vocabulary.

This is useful because one localisation mistake is assuming Chinese users want every technical term translated completely.

In practice, many professional and technical interfaces use a mixture of Chinese terminology and familiar international abbreviations.

For example:

点击率 (CTR)

can be more immediately recognisable than either:

CTR only

or:

点击率 only

The same principle influenced our approach to PPC budget pacing in Simplified Chinese.

Traditional Chinese Needs Its Own Localisation

Traditional Chinese deserves separate treatment.

It is tempting to think:

We already translated Simplified Chinese, so we can simply convert the characters.

That isn't really localisation.

Traditional Chinese markets have their own vocabulary, writing conventions and interface expectations.

Even where the underlying PPC metric is identical, the preferred terminology can differ.

Traditional Chinese users may also expect a different localisation experience from users in mainland China.

For this reason, we created a separate experience for PPC budget pacing in Traditional Chinese, rather than treating Simplified and Traditional Chinese as interchangeable variants of one page.

For metric-heavy products, this distinction matters.

Then Turkish Broke Our Assumption

Turkey was one of the most interesting examples.

The assumption that every PPC market simply uses CTR, CPC and CPA unchanged does not always hold.

Turkish digital-advertising terminology includes established local abbreviations.

For example:

TO — Tıklama Oranı

can be used for click-through rate.

Likewise, CPC-related terminology can use:

TBM — Tıklama Başına Maliyet

rather than simply reproducing the English acronym everywhere.

That immediately disproved the simple localisation rule:

Never translate PPC acronyms.

Sometimes local terminology is already established.

If SaaS software ignores it, the interface can feel less native than the advertising platforms customers already use every day.

This was therefore an important consideration when developing PPC budget pacing in Turkish.

ROAS Is Different Again

ROAS behaves somewhat differently.

Even in markets where some other abbreviations are localised, ROAS is frequently retained as an international performance-marketing term.

The same is often true of:

ROI

KPI

API

SaaS

These terms have effectively become part of international professional vocabulary.

So localisation cannot simply mean:

Translate every acronym.

Nor should it mean:

Keep every acronym in English.

The correct approach depends on the metric and the market.

The Better Model: Separate the Metric From Its Label

From a software architecture perspective, the cleanest solution is to stop treating the English label as the metric itself.

Internally, the application should use a stable identifier.

For example:

metric.ctr
metric.cpc
metric.cpa
metric.cpm
metric.roas

The internal identity remains constant.

The display layer changes according to locale.

Conceptually:

{
  "en": {
    "metric.ctr": "Click-through rate (CTR)"
  },
  "ja": {
    "metric.ctr": "クリック率 (CTR)"
  },
  "ko": {
    "metric.ctr": "클릭률 (CTR)"
  },
  "zh-CN": {
    "metric.ctr": "点击率 (CTR)"
  },
  "tr": {
    "metric.ctr": "Tıklama oranı (TO)"
  }
}

Now the analytics logic never needs to care what the user sees.

The calculation remains the same:

clicks / impressions

while the presentation layer decides whether the user sees:

CTR

クリック率 (CTR)

클릭률 (CTR)

点击率 (CTR)

or:

Tıklama oranı (TO)

That separation makes internationalisation much easier to maintain.

Full Metric Names Matter More Than Acronyms

Another lesson was that localisation is not only about abbreviations.

Consider:

Cost per acquisition

Depending on the product, advertiser and market, users might encounter:

CPA
cost per conversion
acquisition cost
conversion cost

The underlying technical metric may be identical while familiar product terminology differs.

That suggests a useful architecture.

Layer 1: Internal metric

Stable and language-independent.

Example:

metric.cost_per_conversion

Layer 2: Local display label

What the local user expects to see.

Layer 3: Industry acronym

Displayed where it improves recognition.

This approach is much safer than building application logic around English strings.

Don't Use Machine Translation Alone for Metric Dictionaries

Generic translation works surprisingly well for prose.

It is less reliable for specialist product terminology.

Imagine translating:

Underpacing

literally into 14 languages.

The result might be grammatically correct while sounding completely unnatural to a PPC professional.

The same applies to:

overpacing;
spend velocity;
projected spend;
remaining budget;
billing cycle;
rollover budget;
portfolio pacing;
conversion value.

These aren't ordinary sentences.

They're domain terminology.

That means they should be treated more like API names or database fields than blog copy.

Build a terminology dictionary.

Review it once.

Reuse it everywhere.

PPC Budget Pacing Itself Also Needs Localisation

The localisation issue goes beyond performance metrics.

Even the phrase PPC budget pacing does not necessarily translate neatly across every market.

A direct translation may be technically correct but not match the terminology performance marketers actually use.

That is why we created separate market experiences rather than simply translating one English landing page word for word.

For example:

Each page can use the terminology, examples and language appropriate to that market while describing the same underlying budget-management platform.

This also creates a useful SEO experiment.

Instead of assuming where localisation will generate demand, we can observe which markets begin generating:

search impressions → visits → trials → paying customers

and use that data to guide deeper product localisation.

We Now Think of Localisation as Three Layers

Working through this problem led us to separate three different concepts.

1. Application language

What language does the user interface use?

2. Campaign language

What language are the campaign names, keywords and ads written in?

3. Reporting language

What language should the client receive?

These don't necessarily need to match.

Imagine an agency based in Germany.

The internal team works in German.

They manage:

English Google Ads campaigns;
French Meta campaigns;
Spanish Microsoft Advertising campaigns.

One client wants reports in French.

Another wants reports in German.

The software should not assume one account equals one language.

This became particularly important when we developed multilingual PPC reporting.

PaceWise currently generates white-label client reports in 15 languages:

English
French
Spanish
German
Portuguese
Italian
Dutch
Polish
Turkish
Swedish
Simplified Chinese
Traditional Chinese
Indonesian
Japanese
Korean

The report language can therefore reflect the client rather than the internal working language of the agency.

Campaign Language and Budget Data Are Separate

PPC budget-management software has another useful characteristic.

Budget pacing does not need to understand the meaning of an advertisement to understand:

budget;
spend;
conversions;
CPA;
ROAS;
pacing;
projected spend.

Those values come from advertising-platform data.

So a Japanese campaign can be monitored by the same pacing engine as a Korean, Chinese, Turkish or English campaign.

This separation is important:

campaign language ≠ reporting language ≠ application language

Thinking about those three layers independently creates much more flexible international software.

There Is Also a Product Consistency Problem

Suppose the website says:

CTR

the dashboard says:

Click-through rate

and the report says:

クリック率

Now the same product has three naming conventions for one metric.

That creates unnecessary friction.

A localisation glossary should ideally be shared across:

website;
application;
onboarding;
help centre;
reports;
automated emails;
AI-generated summaries.

One metric.

One approved local term.

Everywhere.

AI Makes Translation Faster — but Not Automatically Correct

AI is extremely useful for localisation.

It can dramatically accelerate initial translation.

But the workflow shouldn't be:

English → AI translation → production

A safer process is:

English source term
↓
AI translation
↓
Check advertising-platform terminology
↓
Check real industry usage
↓
Approve glossary term
↓
Reuse across product

The important part is checking how professionals in that market already communicate.

In a specialist area such as PPC, a technically accurate translation can still be the wrong product terminology.

Localised SEO Needs the Same Discipline

Metric localisation also affects SEO.

Suppose an English page targets:

PPC budget management software

A direct translation may not be the phrase marketers actually search in another country.

The same issue applies to:

paid search

PPC

SEM

SEA

budget pacing

budget management

Different markets use different combinations of English and local terminology.

That's another reason localisation needs keyword research rather than simple translation.

For PaceWise, the first stage is building localised acquisition pages and observing which markets generate meaningful search demand.

The idea is simple:

Let demand determine where deeper product localisation happens next.

If PPC budget pacing in Korean starts attracting qualified agency traffic and trials, that creates a stronger commercial argument for deeper Korean UI localisation.

If PPC budget pacing in Japanese generates even stronger demand, Japan might receive higher product-localisation priority.

SEO can therefore become part of the market-expansion research process.

Don't Translate Brand Names

One rule turned out to be much simpler.

Generally:

Google stays Google.

Meta stays Meta.

Microsoft stays Microsoft.

TikTok stays TikTok.

For example, Simplified Chinese platform labels can use the recognised brand name alongside the local word for advertising:

Google 广告

Meta 广告

Microsoft 广告

TikTok 广告

Traditional Chinese uses:

Google 廣告

Meta 廣告

Microsoft 廣告

TikTok 廣告

Trying to translate recognised global brand names usually makes an interface harder rather than easier to understand.

Localisation should reduce friction.

It does not require every English word to disappear.

Our Practical Rule Today

After working through these markets, our approach is roughly:

Keep the internal metric universal

CTR, CPA, ROAS and the underlying metric IDs remain stable internally.

Translate the human-readable meaning

Give users the local terminology they expect.

Preserve international acronyms where they are familiar

Japanese:

クリック率 (CTR)

Korean:

클릭률 (CTR)

Simplified Chinese:

点击率 (CTR)

Respect established local abbreviations

Turkish:

Tıklama oranı (TO)

rather than forcing CTR everywhere.

Treat individual metrics separately

CTR may behave one way.

ROAS may remain ROAS.

CVR may be better shown primarily through a translated full label.

There is no reason every metric has to follow exactly the same localisation rule.

What We'd Recommend to Other SaaS Teams

If you're internationalising analytics, martech, fintech or any other metric-heavy SaaS product, create a metric localisation specification.

For each metric, define:

Internal key
English name
English acronym
Local name
Preferred local acronym
Whether the English acronym should also appear
Formatting rules
Tooltip definition

For example:

Internal key: metric.ctr
English: Click-through rate
English acronym: CTR
Japanese: クリック率
Display: クリック率 (CTR)

or:

Internal key: metric.ctr
English: Click-through rate
English acronym: CTR
Turkish: Tıklama oranı
Local acronym: TO
Display: Tıklama oranı (TO)

That small amount of structure prevents hundreds of inconsistencies later.

The Bigger Lesson

Localisation isn't about eliminating English.

It's about making a product feel familiar.

Sometimes that means translating a word.

Sometimes that means keeping the English acronym.

Sometimes it means showing both.

And occasionally it means recognising that the local industry already has a different abbreviation.

The right question isn't:

“How do we translate CTR?”

It is:

“What would a PPC professional in this market expect to see?”

That change in thinking produces much better multilingual software.

About the Project

PaceWise is an AI-powered PPC budget pacing and management platform for agencies and performance teams managing Google Ads, Meta Ads, Microsoft Advertising and TikTok.

PaceWise supports campaigns regardless of campaign language and provides multilingual PPC reporting in 15 languages.

As part of our international expansion work, we are developing local experiences for:

PPC budget pacing in Japanese

PPC budget pacing in Korean

PPC budget pacing in Simplified Chinese

PPC budget pacing in Traditional Chinese

PPC budget pacing in Turkish

If you're working on localisation for analytics, ad-tech or another metric-heavy SaaS product, I'd be interested to hear which technical terms created the biggest localisation surprises for your team.

We Localised a PPC SaaS Website Across 15 Languages: What We Learned

Jade Chen — Sun, 01 Nov 2026 11:55:19 +0000

Internationalising a SaaS product sounds simple at first.

Translate the homepage. Add a language selector. Done.

That was roughly where we started.

What we discovered while expanding PaceWise, a PPC budget pacing and management platform, was that translation is probably the easiest part of localisation.

The difficult questions are things like:

Should PPC terminology be translated or left in English?
Does “PPC” even mean the same thing to marketers in every country?
Should CTR, CPA and ROAS stay in English?
Do local landing pages need local currencies if the SaaS subscription is billed in USD?
Should every language get a complete copy of the website?
How do you avoid creating 14 near-duplicate SEO pages?
What happens when German text needs twice as much UI space as English?
How should Chinese, Japanese and Korean be handled?
How do you structure URLs and hreflang without creating a maintenance nightmare?

We recently built 14 additional localised landing experiences alongside our English site, while PaceWise already generated client reports in 15 languages.

Here are some of the things we learned.

1. Translation and Localisation Are Not the Same Thing

The first lesson was obvious once we started doing the work:

A translated page is not necessarily a localised page.

Consider an English headline such as:

PPC Budget Management Software for Agencies

A literal translation may be grammatically correct, but it might not match how paid-media professionals in that country actually search or talk about their work.

In Germany, for example, SEA is widely used in professional search-marketing terminology.

In France, SEA also matters.

In Spanish-speaking markets, SEM frequently appears alongside PPC terminology.

So the goal shouldn't be:

Translate the English keyword.

It should be:

Find the language a PPC professional in that market would naturally use to describe the same problem.

That changed how we approached our local landing pages.

Instead of treating English as the immutable source and translating every sentence literally, we started treating each page as a local marketing page built around the same product.

You can see that approach in the German PaceWise landing page, the French version, and the Spanish version.

2. We Chose One Strong Landing Page per Language First

A tempting approach would have been to translate the entire website immediately.

That would mean dozens of pages multiplied across more than a dozen languages.

It would also mean maintaining hundreds of URLs before we knew whether people in those markets actually wanted the product.

So we chose a simpler model:

one strong localised commercial landing page per priority language/market first.

Each page explains:

the PPC budget-management problem;
how budget pacing works;
Google Ads, Meta Ads, Microsoft Advertising and TikTok support;
forecasting;
overspend and underspend detection;
client reporting;
local use cases;
security and control;
FAQs;
and a clear signup path.

The pages all describe the same underlying SaaS product, but they aren't simply find-and-replace translations.

For example, the German version uses terminology appropriate to German search marketers, while the Japanese PaceWise page is written around Japanese PPC terminology and reading patterns.

This approach also gives us a useful experiment.

Instead of assuming which markets deserve deeper localisation, we can measure:

impressions → organic visits → signup intent → trials → customers

and let actual demand tell us where to invest next.

3. URL Architecture Is a Product Decision Too

International SEO quickly becomes an architecture problem.

We wanted URLs that were:

predictable;
easy to crawl;
easy to maintain;
easy to map with hreflang;
and understandable to users.

So rather than creating separate domains for every market, we kept everything under the main PaceWise domain and created language/market paths.

That keeps domain authority consolidated and makes the localisation system easier to manage.

The important part isn't the exact naming convention.

It is consistency.

Once you choose a structure, changing it later across 15 languages becomes expensive.

4. Hreflang Is Easy to Understand and Easy to Get Wrong

Adding translated pages is only half of international SEO.

Search engines also need to understand the relationship between them.

That means thinking about:

hreflang;
self-referencing canonicals;
reciprocal language references;
x-default;
XML sitemaps;
language selectors;
and crawlable internal links.

One mistake we wanted to avoid was canonicalising every translated page back to English.

If the German page is a genuine German version intended to rank independently, it needs to be treated as its own indexable page.

Likewise, every language version should clearly reference its alternatives.

International SEO becomes much easier when localisation is designed into the URL and template architecture rather than added later as a patch.

5. PPC Acronyms Are More Complicated Than Expected

One of the most interesting questions was what to do with metrics such as:

CTR

CPC

CPA

CPM

CVR

ROAS

Our initial instinct was:

PPC professionals everywhere understand these English acronyms, so leave them alone.

That is mostly true — but not universally.

In many markets, PPC practitioners routinely use CTR, CPC, CPA and ROAS even when the rest of the interface or article is entirely in the local language.

But there are exceptions.

Some platforms use locally established abbreviations in certain languages. In others, the translated metric name is more prominent than the English shorthand.

That led us towards a more robust pattern:

local-language metric name + familiar industry acronym

For example, conceptually:

French: local term (CTR)

German: local term (CTR)

Japanese: local term (CTR)

Korean: local term (CTR)

rather than assuming that either English-only or translation-only is always correct.

The lesson is simple:

don't translate marketing terminology with a dictionary.

Check how professionals and the major advertising platforms actually use it in that market.

6. Brand Names Should Usually Stay Brand Names

This one was much easier.

Google Ads is still Google Ads.

Meta remains Meta.

Microsoft remains Microsoft.

TikTok remains TikTok.

For Chinese versions, for example, it is usually clearer to retain the recognised platform brand and localise the generic descriptor around it rather than inventing a completely translated brand name.

The goal of localisation isn't to translate every possible word.

The goal is to reduce cognitive friction.

Sometimes the most familiar local-language experience includes English terminology.

7. Currency and Language Are Separate Problems

Another question we had was whether localisation meant introducing local subscription pricing.

We decided it didn't.

PaceWise currently operates globally with subscription pricing in USD.

That does not prevent a German page from discussing a €30,000 advertising budget or a Japanese page from demonstrating pacing using yen.

There are really two currencies involved:

the customer's advertising currency

and

the SaaS billing currency.

Those do not need to be the same.

A global SaaS company can bill in USD while still displaying and managing the advertising budgets customers actually use in their own markets.

This reduced a lot of unnecessary complexity.

Multi-currency SaaS billing can always be tested later if conversion data shows that it is commercially worthwhile.

8. Local Examples Make a Page Feel Much More Native

Changing language alone wasn't enough.

A page feels much more relevant when the examples make sense locally.

Instead of every version showing:

Monthly budget: $30,000

a European example can use euros.

A Japanese example can use yen.

The same principle applies beyond currency.

Local terminology, agency wording, FAQs and examples all make a page feel like it was written for the market rather than translated into the market.

This also creates more meaningful differentiation between international pages from an SEO perspective.

9. German Reminded Us That UI Space Is Not Universal

English is relatively compact.

German often isn't.

A button that comfortably says:

Start Free

may require substantially more horizontal space once translated.

Navigation labels expand.

Feature descriptions wrap.

Cards that looked balanced in English suddenly have one item occupying three lines.

This is one reason localisation should influence frontend architecture.

Avoid fixed-width assumptions where possible.

Design for:

flexible containers;
wrapping;
different text lengths;
larger mobile heights;
dynamic buttons;
and variable navigation widths.

If localisation is planned from the beginning, this is manageable.

If every UI component was designed around exact English character counts, it becomes painful.

10. Japanese, Chinese and Korean Need More Than Font Replacement

CJK languages introduced another set of considerations.

Line breaking works differently.

Text density feels different.

Some English technical terminology remains familiar, while other terms should be fully localised.

Traditional Chinese and Simplified Chinese also should not simply be treated as interchangeable character sets.

And localisation goes beyond language selection.

A user should not feel that they are looking at an English layout with foreign characters inserted into it.

Typography, spacing, hierarchy and terminology all contribute to whether software feels genuinely international.

For us, the Japanese version, Simplified Chinese version and Traditional Chinese version gave us useful examples of how different these markets can be from Western-language localisation.

11. We Already Had an Advantage: Multilingual Reporting

Before building the new landing pages, PaceWise already supported multilingual PPC reporting with white-label client reports in 15 languages.

That feature originally existed because agencies often operate differently from the clients they serve.

An agency team may work internally in English while producing reports for clients in:

French;
Spanish;
German;
Portuguese;
Italian;
Dutch;
Polish;
Turkish;
Swedish;
Simplified Chinese;
Traditional Chinese;
Indonesian;
Japanese;
Korean;
or English.

The report language is selected per client.

That architecture taught us an important localisation principle:

language is often a property of the user or client, not of the entire account.

One agency may have a French client, a Japanese client and an English-speaking client simultaneously.

For international SaaS, assuming one account equals one language can be unnecessarily restrictive.

12. Campaign Language and Application Language Are Different

PPC software has another useful characteristic.

Budget pacing does not need to understand the meaning of an advertisement in order to understand:

budget;
spend;
conversions;
CPA;
ROAS;
pacing;
and projected spend.

Those values come from advertising-platform data.

So a campaign named in Japanese can be monitored by the same budget-pacing logic as a campaign named in German or English.

That separation is useful:

campaign language ≠ reporting language ≠ application language

Thinking about those three layers independently makes internationalisation much cleaner.

13. We Didn't Translate Every Page — Deliberately

One lesson from this project was that localisation doesn't need to be all-or-nothing.

There is a sensible progression:

Stage 1: Localised acquisition

Create strong market-specific landing pages and see where organic search and conversion demand appears.

Stage 2: Localised customer experience

Translate onboarding, transactional communication, key help content and high-traffic product screens.

Stage 3: Full product localisation

Invest in complete UI localisation for markets that demonstrate meaningful usage and revenue.

This is especially useful for an early-stage SaaS company.

Instead of spending months translating every obscure setting before acquiring a single customer in a market, localisation investment follows commercial evidence.

14. AI Translation Helps — but Domain Knowledge Still Matters

Modern AI made this project dramatically faster.

But it did not eliminate QA.

AI can produce grammatically excellent language while still choosing terminology that a PPC professional would find strange.

Domain terminology is where generic translation often breaks down.

For paid media, terms such as:

pacing;
underpacing;
overpacing;
paid search;
media spend;
ad account;
billing cycle;
budget rollover;
conversion value;
and portfolio pacing

need contextual decisions.

The best workflow we found was closer to:

AI translation → PPC terminology review → local-market review → consistency check

rather than simply:

English → translate → publish

15. Localisation Creates an SEO Measurement Layer

One benefit we didn't fully appreciate initially is that local landing pages can function as market research.

Search Console can tell us:

which countries generate impressions;
which local keywords Google associates with each page;
where rankings begin appearing;
which pages get clicks;
which markets produce trials;
and eventually which markets produce paying customers.

That gives us evidence for product localisation.

If Japanese traffic begins generating disproportionately strong trial conversion, then Japanese UI localisation becomes easier to justify.

If another language produces almost no meaningful demand, we haven't spent months translating the entire application unnecessarily.

SEO becomes part of the product-market expansion process.

What We Would Do Differently Next Time

If we were designing a multilingual SaaS architecture from day one, we would formalise several things earlier.

Build a terminology glossary

Define the approved translation for every recurring concept:

budget

spend

remaining budget

pacing

forecast

overspend

underpacing

billing cycle

The glossary becomes the source of truth for website copy, reports, UI and help content.

Separate strings from product logic

Instead of:

"Budget remaining"

use something conceptually like:

budget.remaining

Then each locale supplies its own display text.

That sounds obvious, but retrofitting internationalisation is much harder than designing for it.

Test longer strings early

Use pseudo-localisation or intentionally long labels during frontend development.

If the UI survives those, German probably won't destroy it later.

Automate international SEO QA

We would also test automatically for:

missing hreflang references;
broken language links;
incorrect canonicals;
missing titles;
duplicated metadata;
unsupported locale codes;
and pages missing from the sitemap.

Once you have more than a dozen variants, manual checking stops scaling quickly.

The Bigger Lesson

Internationalising software isn't really a translation project.

It touches:

product architecture

frontend design

SEO

terminology

billing

reporting

analytics

content strategy

customer experience

The most useful mindset change for us was this:

Don't ask, “How do we translate our English product?”

Ask:

“How would someone in this market expect this product to work and communicate?”

Those are very different questions.

We are still early in the process.

The localised landing pages are an experiment, not the endpoint. The next step is watching which markets actually respond and using that data to determine where deeper product localisation makes commercial sense.

For PaceWise, that could eventually mean a user searches for PPC budget-management software in their own language, lands on a local experience, manages international campaigns through the same platform and sends every client a report in the language they prefer.

That's the kind of internationalisation worth building.

About the Project

PaceWise is an AI-powered PPC budget pacing and management platform for agencies and performance teams. It monitors advertising budgets across Google Ads, Meta Ads, Microsoft Advertising and TikTok, with forecasting, pacing alerts, controlled automation and white-label client reporting in 15 languages.

If you're working on international SaaS, ad-tech or localisation architecture, I'd be interested to hear which parts of localisation created the biggest surprises for your own product.

How PPC Budget Pacing Automation Replaces Spreadsheet Workflows for Agencies

Jade Chen — Sun, 01 Nov 2026 11:40:31 +0000

Paid advertising platforms have become increasingly automated.

Google Ads, Meta Ads, Microsoft Advertising and TikTok can automate bidding, targeting, audience expansion and campaign delivery. Yet many agencies still manage one of the most financially important parts of paid media with a spreadsheet:

budget pacing.

For a small number of campaigns, this can work perfectly well.

But once an agency manages 10, 20 or 50+ PPC clients across several advertising platforms, the workflow starts to break down.

The problem is not that spreadsheets are bad.

The problem is that spreadsheets are static, while advertising spend is continuously changing.

What Is PPC Budget Pacing?

PPC budget pacing is the process of monitoring advertising spend against an allocated budget throughout a billing period.

At a basic level, the calculation asks:

If spending continues at the current rate, will the account finish close to its target budget?

For example, imagine a client has a monthly advertising budget of $30,000.

Halfway through the billing cycle:

$15,000 spent may indicate the account is approximately on pace.
$22,000 spent could indicate a potential overspend.
$8,000 spent could signal significant underpacing.

But real PPC budget management becomes more complicated because spend rarely follows a perfectly straight line.

Campaigns change.

Demand changes.

Budgets move.

Promotions begin and end.

Algorithms alter delivery.

That means modern pacing requires more than:

monthly_budget ÷ number_of_days

A useful system needs to continuously evaluate actual spend, elapsed time, remaining budget, recent spend velocity and projected period-end spend.

Why Spreadsheet-Based Pacing Becomes Difficult

A typical manual agency workflow might look like this:

Open Google Ads.
Check client spend.
Open Meta Ads.
Check client spend.
Repeat for Microsoft and TikTok.
Copy figures into a spreadsheet.
Recalculate pacing.
Identify accounts that appear off track.
Notify account managers.
Repeat tomorrow.

Multiply that by 30 clients.

Now multiply it again across multiple team members.

Suddenly budget pacing becomes an operational system rather than a simple spreadsheet.

This is one reason specialist PPC budget management software for agencies is becoming more useful as agencies scale.

The objective is not simply to replace Excel or Google Sheets.

It is to change the workflow from:

Check every account to find the problems

to:

Automatically surface the accounts that require attention

API-Based Data Collection Changes the Workflow

A modern pacing platform can connect directly to advertising platforms through their APIs.

Instead of manually exporting spend figures, campaign data can be pulled automatically and recalculated on a frequent schedule.

For example, PaceWise connects to supported advertising platforms and refreshes campaign data every 15 minutes.

This creates a very different operational model.

Rather than a spreadsheet representing a snapshot taken yesterday morning, teams get a continuously updated view of how client budgets are tracking.

For Google Ads specifically, Google Ads budget pacing software can pull active campaign spend through Google's API and recalculate pacing against the client's defined budget.

The same concept applies across a multi-platform portfolio.

Pacing Is More Useful When It Is Predictive

Historical spend tells you what has happened.

Forecasting tells you what may happen next.

Consider two campaigns:

Campaign A

Budget: $30,000
Spend to date: $18,000
Projected spend: $29,700

Campaign B

Budget: $30,000
Spend to date: $18,000
Projected spend: $37,400

Both have spent exactly the same amount.

But they have completely different risk profiles.

Campaign B requires attention.

That is why forecasting is an important part of modern PPC budget pacing.

The useful question is not:

"How much have we spent?"

It is:

"Where are we likely to finish?"

Once that answer is available across every client account, the team can prioritise work much more intelligently.

Overspending Is Not the Only Failure Mode

Budget-management systems often focus heavily on overspend.

Understandably so.

If an agency spends substantially more than the client approved, it can create an uncomfortable conversation very quickly.

But underspending is also a problem.

Suppose a client allocates $100,000 because there is profitable demand available.

If only $70,000 is deployed, the remaining $30,000 may represent lost leads, sales or market share.

A useful pacing system therefore needs to recognise both:

overpacing
underpacing

The goal isn't simply to spend less.

The goal is to keep investment aligned with the media plan.

Multi-Platform PPC Creates Another Layer of Complexity

A client's advertising budget may be distributed across:

Google Ads
Meta Ads
Microsoft Advertising
TikTok Ads

From the client's perspective, it is still one marketing investment.

From the agency's perspective, it may exist across four completely different interfaces.

That fragmentation makes budget governance harder.

One channel might be underspending while another is accelerating rapidly.

Checking each platform independently can hide the portfolio-level picture.

A central pacing layer helps answer a much simpler question:

Is the client's total PPC investment on track?

Platforms such as PaceWise are designed around this cross-platform budget-management problem, combining spend visibility, pacing, forecasting, alerts and reporting in one environment.

Exception-Based Management Is More Scalable

The biggest efficiency gain doesn't necessarily come from faster calculations.

It comes from changing what humans spend time looking at.

Imagine an agency manages 50 client accounts.

On a particular morning:

41 are pacing normally.
5 are slightly under target.
3 are trending above budget.
1 has experienced an unusual spend spike.

A spreadsheet workflow may still require someone to review all 50.

An exception-based system can surface the nine accounts that deserve attention — especially the four with material risk.

That leaves account managers with more time for:

optimisation
analysis
client strategy
creative testing
conversion improvement

Automation is most valuable when it removes repetitive monitoring rather than replacing strategic judgement.

AI Should Support Budget Decisions, Not Hide Them

AI is increasingly being used to interpret campaign data and recommend actions.

But paid media budgets involve real client money.

That makes transparency important.

A useful model is:

AI identifies → AI recommends → human reviews → controlled action occurs

For example, a system might identify an overpacing campaign and recommend shifting budget within the same advertising channel.

The account manager can then review:

which campaign is affected
how much budget would move
why the recommendation was made
how pacing would change

before approving anything.

This creates a useful middle ground between purely manual management and completely autonomous campaign control.

Reporting Is Part of the Same Data Problem

Agencies often solve budget pacing and client reporting as two separate workflows.

But both rely on essentially the same underlying data.

If the agency has already collected:

budget
actual spend
pacing
conversions
CPA
ROAS
projected spend

then rebuilding all of that manually for a client report creates duplicated work.

This is why reporting can logically sit alongside pacing.

PaceWise, for example, provides multilingual PPC reporting with white-label reports in 15 languages.

For agencies managing international clients, that means the same underlying campaign data can support both internal budget governance and external client communication.

Custom Billing Cycles Matter More Than They Look

Another common spreadsheet assumption is:

Every client's budget runs from the 1st to the last day of the month.

In reality, agencies encounter clients with different billing arrangements.

A client may reset its monthly budget on the 15th.

Another may carry unused budget forward.

If the pacing model uses the wrong date range, even a mathematically correct calculation can produce the wrong operational conclusion.

That is why scalable pacing systems need to account for:

custom monthly reset dates
rollover budgets
changes to allocated spend
different portfolio structures

The pacing logic needs to reflect the client's actual budget rules.

When Does an Agency Outgrow a Spreadsheet?

There isn't a universal number.

But some warning signs are obvious:

multiple people maintain separate pacing sheets;
account managers manually check spend every day;
budget problems are discovered late;
client reporting takes hours every month;
teams manage several advertising platforms;
different clients use different billing cycles;
senior PPC specialists spend significant time copying numbers between systems.

At that point, automation is no longer just a convenience.

It becomes an operational scaling decision.

The goal isn't to eliminate spreadsheets from marketing.

It's to stop using them as a pseudo-database, monitoring system, forecasting engine and alerting platform all at once.

The Future of PPC Budget Management

Paid media platforms will continue automating more campaign-level decisions.

That makes budget governance more important, not less.

As algorithms gain more control over bidding and delivery, teams need a reliable layer that answers:

What has been spent?
What remains?
Are we on pace?
Where are we projected to finish?
What changed?
Which account needs attention?
What action should we consider?

That is the role modern PPC budget pacing software can play.

The future probably isn't a bigger spreadsheet.

It is a combination of API-based data collection, frequent pacing calculations, forecasting, anomaly detection, intelligent alerts and controlled automation.

For teams exploring this approach, the PaceWise PPC budget pacing guide goes deeper into how PPC pacing works and why it matters as paid media becomes increasingly automated.

And for agencies managing multiple accounts, PaceWise provides a dedicated environment for monitoring PPC budgets across clients and platforms without rebuilding the same workflow in spreadsheets every day.

Better automation doesn't remove the marketer from budget management. It gives the marketer better information about where attention is actually needed.