From Customer Value Analysis to Daily Marketing Activation

The challenge

Customer value is useful only when it changes what the business does next.

We had customer data and a clear interest in value-based marketing, but the process of turning that data into updated marketing audiences involved several separate steps. Data needed to be refreshed, customers needed to be classified, upload files needed to be prepared, and the final audiences needed to be delivered to Google Ads.

That created three practical risks:

• The data could become outdated before it was activated.
• Customer classifications could be applied inconsistently.
• Manual file handling could make the process slow and difficult to scale.

The objective was not simply to calculate customer lifetime value. The objective was to create a reliable path from customer data to daily marketing action.

The objective

We built an automated workflow that could:

• Read the latest customer data from Tableau.
• Prepare and standardise the data.
• Apply customer value and behaviour rules.
• Assign each customer to an actionable tier.
• Create Google Ads-ready upload files.
• Refresh the outputs every day.
• Provide enough monitoring to validate the process before using the audiences for bidding.

This approach separated data quality and audience validation from campaign performance testing. That distinction was important: a successful upload does not automatically prove that a segment will improve ROAS.

The methodology

The workflow combined customer value with purchase behaviour. Rather than treating all customers as one audience, we created segments designed to support different marketing decisions.

High-value customers

Recurring customers with the strongest value signal. These customers were candidates for retention, loyalty, and carefully controlled expansion strategies.

Mid-value customers

Recurring customers with meaningful value but further room for development. This segment could support retention and progression strategies.

One-off customers

Customers with recorded value but no recurring purchase pattern. These customers were relevant for second-purchase and reactivation initiatives.

Churned customers

Customers with no recent value and no recent activity. This group could be used for controlled reactivation tests, rather than being treated as one undifferentiated inactive audience.

The original classification used 90-day lifetime value and customer behaviour. The thresholds were based on the observed distribution of customer value, including median and upper-quartile reference points, rather than arbitrary business cut-offs. The methodology later evolved toward GMV-based fields for relevant time windows so the segmentation could align more directly with commercial outcomes.

A light technical view

The data-processing layer was built in Python using a tabular, customer-level data model. Each row represented one customer, while columns represented identifiers, purchase behaviour, and value signals used for segmentation.

The main structure was a pandas DataFrame with fields such as:

• Customer identifier and hashed contact information for audience activation.
• Purchase frequency or recurrence indicator.
• Recent activity and event counts.
• 90-day value metrics.
• GMV windows such as one-month weekly, one-month biweekly, and one-to-three-month value.
• Final customer tier.

The transformation pattern was deliberately simple and auditable:

Raw customer data
→ type and field standardisation
→ missing-value handling
→ value and behaviour features
→ threshold calculation
→ rule-based tier assignment
→ upload schema and export

The principal Python libraries were:

• pandas for DataFrame-based cleaning, joins, aggregations, filtering, and tier assignment.
• NumPy for numerical operations and conditional logic where needed.
• Google authentication and API client libraries for authenticated access to Google services.
• gspread or the Google Sheets client layer for reading and writing spreadsheet outputs, depending on the deployed implementation.
• json and os from the Python standard library for reading configuration and environment variables.
• logging from the standard library for operational messages and troubleshooting in Cloud Run.

The tiering itself was rule-based rather than a black-box model. That was intentional. At this stage, transparency was more important than model complexity: the team needed to understand why a customer was assigned to a particular segment and to be able to adjust the thresholds later.

A simplified version of the decision logic looked like this:

if recurring and value_90d >= upper_threshold:
    tier = "HIGH_VALUE"
elif recurring and value_90d >= lower_threshold:
    tier = "MID_VALUE"
elif value_90d > 0:
    tier = "ONE_OFF"
elif value_90d == 0 and events_90d == 0:
    tier = "CHURNED"

The production workflow also incorporated the relevant GMV-based fields as the project evolved. This allowed the business logic to move from a single LTV measure toward a more commercially aligned view of recent customer value.

The workflow

The full process was designed as a connected chain:

Tableau
   ↓
Daily data preparation
   ↓
Customer value and behaviour signals
   ↓
Tier assignment in Python
   ↓
Upload-file creation
   ↓
Google Ads Customer Match audiences
   ↓
Future bidding and optimisation

The data-processing service was deployed on Google Cloud Run. Google Cloud Scheduler triggers the service once per day through an HTTP request. The service processes the latest available data, applies the classification logic, generates the output, and writes the result to the connected Google Sheets workflow used for inspection and upload preparation.

Google Cloud documents Cloud Scheduler as a managed service for running jobs on a schedule, including HTTP requests to Cloud Run services. Google Ads Customer Match supports uploading customer data into customer lists and provides upload-related information that can be used to validate the data hand-off. Cloud Run and Cloud Scheduler · Google Ads Customer Match

From manual work to a repeatable process

Before automation, the workflow depended on manual coordination:

• Refresh or locate the latest data.
• Recreate the customer segments.
• Prepare the upload files.
• Deliver the files to the advertising platform.
• Check whether the process completed correctly.

After automation, the process became repeatable:

• A daily scheduler triggers the service.
• The latest data is processed using the same rules.
• Customers are assigned to tiers consistently.
• Upload files are created automatically.
• The result can be checked through logs, Google Sheets, and Google Ads upload status.

The purpose of automation was not to remove human judgement. It was to move human effort away from repetitive file preparation and toward strategy, testing, and optimisation.

Validation before bidding

We intentionally validated the workflow in stages.

1. Technical validation

We checked whether:

• The scheduled service ran successfully.
• The output was generated on time.
• The expected number of rows was processed.
• The Google Ads upload accepted the data.
• The audience showed a usable match rate.

These checks answer the question: Did the data pipeline work?

2. Classification validation

We checked whether:

• Tier sizes were plausible.
• Higher-value groups had higher average value than lower-value groups.
• Recurring customers were separated from one-off customers.
• Customers did not move between tiers unpredictably because of small daily fluctuations.
• The classification covered the active customer base adequately.

These checks answer the question: Does the segmentation represent real customer differences?

3. Marketing validation

Only after the first two layers are reliable should the segments influence bidding or budgets.

The next stage is to compare outcomes by tier using metrics such as:

• Conversion rate.
• Cost per conversion.
• Revenue or margin per customer.
• Repeat purchase rate.
• Incremental revenue.
• Return on ad spend.

These checks answer the question: Does the segmentation improve marketing decisions?

What happened during deployment

The first scheduled run failed. Cloud Scheduler reached the Cloud Run service, but the application returned an HTTP 500 error. The logs showed a Python KeyError caused by a missing GOOGLE_SERVICE_ACCOUNT environment variable.

We restored the required configuration, deployed a new Cloud Run revision, and ran the scheduler job again manually. The second run completed successfully.

This was an important lesson: deployment is not the same as operational readiness. An automated workflow is only complete when it is observable, testable, and recoverable.

Current status

The data refresh, tiering, file creation, and scheduled upload workflow are operating successfully. The audiences have been uploaded and monitored, but bidding has not yet been changed based on the new classifications.

That means the current project status should be described accurately:

• The pipeline is operational.
• The classification is being validated.
• The uploads are being monitored.
• The commercial impact of bidding by tier is the next stage.

This distinction prevents us from claiming ROAS improvement before a controlled advertising test has taken place.

What success looks like

At the current stage, success means that the workflow produces reliable and useful audiences.

The main indicators are:

• Daily refreshes complete successfully.
• Tiering rules are applied consistently.
• Upload files are generated without manual reconstruction.
• Google Ads accepts the uploaded data.
• Match rates and audience sizes are usable.
• The tiers show meaningful differences in customer value and behaviour.

Once bidding begins, the success criteria will expand to include conversion efficiency, incremental value, repeat purchase behaviour, and ROAS.

Next steps

The next phase is controlled activation rather than immediate broad rollout.

We can begin by applying the audiences to selected campaigns, establishing a baseline, and comparing performance over a defined test period. The test should separate the effect of the audience classification from other changes such as creative, budget, landing pages, seasonality, or campaign structure.

Over time, the workflow can support more advanced optimisation:

• Test different bidding strategies by customer tier.
• Compare acquisition, retention, and reactivation use cases.
• Measure incremental lift rather than relying only on attributed conversions.
• Tune the tier thresholds based on observed business outcomes.
• Develop predictive CLTV or propensity models once enough outcome data is available.

Conclusion

This project started as a customer value classification exercise. It became a practical operating system for value-based marketing.

The workflow now connects fresh customer data, business rules, customer tiering, audience creation, and scheduled delivery. That connection turns customer value from a reporting concept into something the marketing team can use every day.

The main achievement was not a single formula or upload. It was building a dependable bridge between understanding customers and acting on that understanding.