Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

How to Test WooCommerce Analytics Without Polluting Revenue Reports

A test purchase can trigger WooCommerce revenue, gateway records, email, stock, CRM, advertising conversions and GA4. Deleting the order later does not reliably remove those effects. A useful test plan isolates measurement before the first event is sent.

Use dedicated test identities and document every transaction ID. Never use a real customer’s account or personal data.

Choose the test boundary

For development and staging, use a separate GA4 property or data stream and gateway sandbox. Prevent staging from indexing, sending production email or reaching fulfilment.

For a production-only defect, use an approved low-value product and payment procedure. Decide beforehand how accounting, refund and stock cleanup will work.

Test record:
environment and GA measurement ID
WooCommerce order/transaction ID
gateway mode
expected analytics events
cleanup owner and date

Keep credentials and payment details out of the record.

Use GA4 DebugView

Enable debug mode only for the controlled browser or Tag Manager preview session. DebugView lets you inspect event order and parameters without waiting for standard reports.

Confirm view_item, add_to_cart, begin_checkout and purchase as appropriate, but do not judge transaction correctness from event names alone.

Check transaction_id, numeric value, ISO currency and item IDs. Do not send email, name, address, phone, order key or payment token.

Separate staging and production data

A hostname filter inside a report is weaker than preventing staging data from entering the production property. Use distinct configuration wherever practical.

If one property must receive several environments, include a non-personal environment parameter and create internal testing views/explorations with clear governance. GA4 data filters can be irreversible once active, so test them before permanent use.

Document which measurement ID each deployment should load.

Create identifiable production tests

Use a unique transaction reference and test product/SKU approved for analytics validation. Avoid inserting words such as “test” into customer fields that are then sent to third parties.

Do not fake a purchase event from the browser console as the only test. It proves tag transport, not the WooCommerce-to-data-layer integration or payment lifecycle.

One controlled order should exercise the complete route.

Prevent advertising side effects

Google Ads, Meta and affiliate tags may treat the same purchase as a real conversion. Review Tag Manager triggers and use an approved test/environment condition across marketing tags.

Consent choices must still be honoured. Do not bypass consent solely because the buyer is staff.

Coordinate with campaign owners before production tests; automated bidding can consume conversion signals even when Analytics reports later exclude them.

Inspect without repeated purchases

Use Tag Manager preview, browser Network and GA4 DebugView on one order. Refreshing the thank-you page should not produce another logical purchase.

If a fix requires another transaction, reconcile and close the first one before proceeding. Reusing the same WooCommerce order for unrelated tests can hide deduplication defects.

Test browser and server event sources separately where both exist.

Clean up operational effects

Refund a real test charge through the provider’s normal workflow, restore stock deliberately and mark the order according to accounting policy. Do not delete a paid order and pretend the money movement never occurred.

Remove test CRM, shipping and email effects through supported tools. Keep a private note linking the reason and refund reference.

Analytics events already collected may remain; use documented report segments/exclusions rather than claiming they were erased.

Turn the test into monitoring

Save a checklist containing environment, consent state, device, gateway, expected event sequence and acceptance criteria. Repeat it after checkout, theme, consent or tag releases.

Compare unique purchase transaction IDs with a bounded set of paid WooCommerce orders. Exact equality is not always expected because of consent and browser loss, but duplicates, missing-all events or sudden divergence deserve alerts.

A clean measurement practice protects both decision-making and customer privacy while still testing the complete commercial journey.