Conversion tracking · Malaysia

Know what your conversion numbers actually count.

Conversion tracking connects a customer action to the reports you use for budget decisions. For Malaysian businesses using GA4, Google Tag Manager and ad platforms, we define the important actions, set up or repair the agreed events and test what each tool receives.

When the numbers disagree.

A WhatsApp-button click records an attempt to open a contact route; it does not prove the visitor sent a message. A form event can fire before the submission succeeds. If all of these appear as leads, your team cannot tell how many real enquiries arrived or which numbers to trust.

01

Different tools count different actions

A button click, a successful form submission and a sale describe different actions. Their definitions need to be agreed before totals are compared.

02

One submission may trigger twice

One form submission can be recorded by more than one tag or event path. If the same action is counted twice, cost per conversion looks lower at unchanged spend. We check whether repeated records are duplicates or separate actions.

03

Test evidence is missing

The team cannot show which successful submissions and failed attempts were checked after implementation.

04

Website actions are confused with sales

A submitted enquiry does not prove a sale. Sales stages require separate usable records and an agreed connection.

Make the next decision easier to explain.

01

Define each action clearly.

With each action defined before tags are added, your reports can distinguish a click, a submitted enquiry and a later sales stage.

02

Test the agreed event paths.

We check successful submissions, failed attempts and possible duplicates against the measurement specification, so you know whether a repeated record is double counting or a separate request.

03

Leave usable test evidence.

You keep a record of the actions checked, known limits and who maintains the setup, so your team or developer can retest when the website changes.

Measure the enquiry that actually arrived.

We map each step from a first click to an enquiry your sales team confirms as a fit. The checks below keep what the website records separate from what only sales evidence can show.

For example, a maintenance provider’s successful quote form and WhatsApp-button click record different actions; neither alone proves a qualified enquiry.

Laptop form, phone confirmation and checklist used to plan enquiry testing.
  1. 01 / ActionAn enquiry accepted by the website

    We define success after the form is accepted. A button press or attempted submission is a different action.

  2. 02 / EventA stable name and necessary data

    We record the event name, trigger and permitted parameters. Names, email addresses and phone numbers stay out of analytics event fields.

  3. 03 / ToolsGA4 and the agreed ad destinations

    We agree which actions matter in each tool. GA4 key events and advertising conversion goals have different roles and settings.

  4. 04 / TestsSuccess, failure and repeat submissions

    We check whether the event fires at the right time and whether duplicate collection is possible, across the agreed consent states and devices named in the proposal.

  5. 05 / QualitySales confirms fit and need

    A qualified enquiry or completed sale needs its own record. Any CRM or offline conversion connection must be agreed and tested.

Illustrative planning example, not a client case study.

Define, implement and verify the agreed actions.

The proposal names the work included, approval rights and people responsible. Open each part to read its boundaries.

01

Measurement plan

Make each event mean something specific.

See what this covers

We list forms, contact clicks, purchases or other agreed actions and define their triggers, data requirements, destinations and owners. We also identify which actions are reporting signals and which advertising goals are intended to guide bidding.

02

Setup or repair

Work within the site and tools available.

See what this covers

We review GA4, GTM and the selected platform events. The proposal names the setup or repair we will implement and what your developer must supply. Custom data layers, server events, browser/server deduplication and CRM imports need explicit scope, access and ownership.

03

Testing and handover

Leave evidence the team can check later.

See what this covers

We test the agreed success and failure paths, relevant consent states and duplicate risks, then record expected events, observed results and unresolved limits. We explain how to retest after a form, website or platform change.

Define the action before adding the tag.

Each step ends with a decision or check your team can use later.

  1. 01

    Agree what counts

    We write down the business action, success condition and destination for each event, and you approve the list.

  2. 02

    Implement and test

    We configure the agreed events, working with your developer where the proposal names their part, then check actual collection, including failure and duplicate cases.

  3. 03

    Hand over the checks

    We document event settings, test evidence, limitations and the person who will retest after changes.

A measurement specification with test evidence.

The specification records what each number counts, how the agreed event was tested and which limits remain. Your team can use it to retest after changes. Better collection can improve future reporting; it cannot fill gaps in past data.

Illustrative business example

A record the next person can use.

Illustrative deliverable register. These are fields to agree before work, not completed findings or results.

  1. 01 / Decision
    What was agreed

    Record the agreed success condition, event destination and person approving the definition.

  2. 02 / Evidence
    What supports the decision

    Record the account, page or event reviewed and distinguish an observed fact from a question still open.

  3. 03 / Next check
    Who checks what happens next

    Name the person responsible, the agreed action and what evidence is needed at the next review.

This is a planning example, not a client case study. No campaign results, costs or sales outcomes are implied.

Agree the people and responsibilities before work begins.

Tracking touches your website, reporting tools and enquiry records, so each part needs a named owner.

Aaron reviewing papers during a discussion.

Your business approves measurement and data use.

You confirm which actions count, your consent requirements and what customer data may be used. We work within those decisions and do not make them for you.

Name the person responding to enquiries.

Record what arrived and whether it fits. Sales confirming fit is a separate step from a submitted form.

Confirm technical and production scope.

Landing-page development, original creative, server events and CRM integrations need an explicit agreement and owner.

Check whether this is the right starting point.

Select the points that apply to your project.

Good fit when

Not the right start when

  • You need guaranteed leads, sales or a fixed cost per enquiry.
  • The service or buyer is still undefined.
  • Nobody can approve the work or respond to enquiries.

Tracking questions.

The answers should match the account, website and sales process you actually have.

What deliverables are included in the agreed scope?

Your proposal lists the agreed event map, changes we implement or repair, test log, known limitations and retesting notes. Work outside that list, including server events or a CRM integration, needs an explicit agreement.

What access and people are needed?

We need access to GA4, Google Tag Manager and the relevant ad account or event settings, plus the website owner. Your business decides consent requirements and approves permitted data use. A developer may be needed for custom forms, data layers or server events, and your sales team supplies records if offline qualification is in scope.

How should we judge the results?

By whether the agreed actions are recorded as defined and pass the agreed tests. The test log shows which successful, failed and repeat submissions were checked. Clicks, submitted enquiries, enquiries your sales team confirms as a fit and sales stay separate measures. Where sales or attribution evidence is missing, we state that limit. Correcting duplicate counting can reduce reported conversions and raise reported cost per conversion at the same spend, even when actual enquiries have not changed.

Is implementation included?

Yes, for the event setup or repairs agreed in your proposal, within the website and tools it names. The proposal states the changes we make, who approves them and what your developer supplies. Server events, customer relationship management (CRM) integration, landing-page development and creative production are not assumed; each needs an explicit agreement. If you want a review before deciding which changes to make, our Paid Media Audit is a separate service.

Can a WhatsApp-button click confirm a conversation?

No. It records an attempt to use a contact route. Confirming that a message or useful conversation occurred requires separate enquiry or sales evidence.

When should a form count as a successful enquiry?

When the website accepts the request, not when someone presses the button. A button press, attempted submission and failed form are different actions, so we test the agreed paths separately. An accepted request does not by itself confirm enquiry quality or a sale.

Why might one submission appear more than once?

Because more than one tag or event path can record the same action. We test the agreed paths and distinguish duplicate collection from someone genuinely submitting twice. Where browser and server events are both in scope, we agree how their duplicates will be checked.

Can GA4 and ad-platform totals be expected to match exactly?

Not always. Action definitions, attribution, identity, consent, counting and reporting settings can differ. For example, GA4 key events can count each trigger, while a Google Ads conversion action may be set to count one conversion after an ad interaction. We check that the agreed events are collected as defined and state the limits when comparing reports.

Can new tracking recover actions that were never recorded?

No. Better collection can improve future reporting, but cannot recreate missing historical actions or guarantee perfect attribution.

What needs checking after the website changes?

The agreed actions need retesting after changes to forms, pages, consent settings or event settings. A change can stop an event firing or make it fire twice. The handover notes list the expected events, observed results, known limits and person responsible.

A practical place to begin

Bring the actions your report needs to distinguish.

Share the offer, current channels and what you need to understand about enquiry quality.