Removing test and spam submissions from reporting

Exclude confirmed tests and spam from the genuine-enquiry count under documented, reviewable rules. Keep the raw intake count and every exclusion visible. A filter that quietly drops a real request harms reporting and the response process.

Classify before excluding

Staff tests, automated abuse and customer requests each require different treatment. A repeated transmission of a real request belongs under the deduplication rule, not a spam bucket. A real request for a service the business does not offer remains a genuine assessed enquiry.

Define who may change a classification and how a reviewer can inspect the basis while the underlying record is lawfully retained. A vague or unfamiliar address is not sole proof of spam.

Separate protection from classification

A protection tool may reduce automated traffic, but its output does not assess project fit. If reCAPTCHA v3 is used, Google describes a risk score and says to send the response token to the backend for verification. Google says reCAPTCHA learns from real traffic and suggests acting behind the scenes rather than blocking traffic.

Review uncertain cases and whether genuine people can still send requests. A low score alone does not establish that a submission is not a genuine request.

Give staff and agencies an agreed way to mark test submissions. Confirm which actual request arrived before excluding it from the report. An office IP rule may miss a test submitted from home.

Treat analytics filtering and CRM classification as separate tasks. An analytics rule alone does not establish whether a submission is a test, spam or genuine. Check the underlying intake record before excluding it.

Reconcile without double counting

For each received period, start with distinct successful submissions. Classify confirmed tests and spam, then link repeated genuine submissions to their underlying enquiries. Apply each submission to one applicable step only and show pending reviews separately.

The resulting count is distinct genuine enquiries under the stated rule. If the rule changes, date the change before comparing periods.

Check configured events against intake records before using a difference as evidence of spam.

After a rule change, sample both excluded and included cases. Excluded cases can reveal real requests wrongly removed; included cases can reveal abuse left in the total. Record the result without copying abusive or personal message text into widely shared reports.

Retain only what is needed

Limit access to records used for review and apply the organisation's retention rules. For entities covered by the Australian Privacy Principles, APP 11 requires reasonable security steps and, subject to exceptions, reasonable steps to destroy or de-identify personal information no longer needed for a permitted purpose. An exclusion label does not settle how long the record may be held.

Before closing a review, check each excluded record has a documented reason. Ensure unresolved cases remain identifiable for review.

Key Compliance Requirements for Personal Information Handling