Google Data Manager API documents TOO_FEW_ELEMENTS when the number of elements in a field is less than the minimum allowed. In a WordPress lead or WooCommerce event pipeline, that often happens when normalization, validation, consent, deduplication, destination mapping, or empty-value filtering removes every entry from a repeated field that the selected event shape requires.
Use this for WordPress forms, WooCommerce orders, CRM lead imports, offline conversions, audience data, custom event builders, and server-side jobs that send repeated identifiers, destinations, items, or other collections to Data Manager API.
Quick answer
Data Manager API TOO_FEW_ELEMENTS Boundary Test should be handled with a narrow evidence-first workflow: count source elements, trace each filter, match the exact schema, then verify the result before making broader changes.
What to check first
- Capture the sanitized source record before transformation and count each repeated field without logging raw email, phone, address, or other personal data.
- Record element counts after normalization, consent enforcement, invalid-value removal, deduplication, destination routing, batching, and final request serialization.
- Compare the rejected field path and request ID with the official schema and the exact destination or event type instead of applying one minimum to every collection.
- Create boundary fixtures with zero, one, the expected minimum, one above the minimum, optional field omitted, and optional field present as an empty array.
- Reject or quarantine invalid records locally, preserve reason codes, and prove that one bad record does not hide accepted records in the same job.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Count source elements | Capture the sanitized source record before transformation and count each repeated field without logging raw email, phone, address, or other personal data. | Element counts are recorded before and after every transformation without exposing personal data. |
| Trace each filter | Record element counts after normalization, consent enforcement, invalid-value removal, deduplication, destination routing, batching, and final request serialization. | Zero, minimum, above-minimum, omitted, and empty-array fixtures produce the documented local and API results. |
| Match the exact schema | Compare the rejected field path and request ID with the official schema and the exact destination or event type instead of applying one minimum to every collection. | Accepted records continue while rejected records retain field path, reason, request ID, and retry eligibility. |
| Build boundary fixtures | Create boundary fixtures with zero, one, the expected minimum, one above the minimum, optional field omitted, and optional field present as an empty array. | The corrected record uses only real source values with the required consent and is not uploaded twice. |
Why this usually happens
- The source contains a value, but normalization removes it as invalid or blank.
- Consent rules intentionally remove identifiers while the event builder still includes the empty field.
- An optional collection is serialized as an empty array instead of being omitted.
- Deduplication or destination filtering removes the last remaining element after an earlier count passed.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
boundary_case:
record_id: lead-test-1048
field_path: events[0].user_data.identifiers
source_count: 2
normalized_count: 1
consent_allowed_count: 0
serialized_count: 0
api_reason: TOO_FEW_ELEMENTS
local_action: quarantine
request_id: sanitized-reference
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Count source elements
- Trace each filter
- Match the exact schema
- Build boundary fixtures
- Quarantine locally
Decision rule
Send the collection only when real, consent-appropriate values meet the exact schema for that event and destination. Omit an optional field when allowed, reject a record missing required elements, and never pad a request with placeholders or copied identifiers.
What to tell the client or owner
Provide destination and event type, sanitized record ID, rejected field path, source and post-filter counts, consent outcome, serialized request shape with personal data removed, API reason, request ID, local validation result, and retry state.
Production verification checklist
- Element counts are recorded before and after every transformation without exposing personal data.
- Zero, minimum, above-minimum, omitted, and empty-array fixtures produce the documented local and API results.
- Accepted records continue while rejected records retain field path, reason, request ID, and retry eligibility.
- The corrected record uses only real source values with the required consent and is not uploaded twice.
Mistakes to avoid
- Do not add fake values to satisfy a minimum.
- Do not log raw identifiers while diagnosing element counts.
- Do not treat omitted and empty arrays as interchangeable without checking the schema.
- Do not retry an unchanged permanent validation error.
Questions teams ask during testing
Can I omit the field instead of sending an empty array?
Only when the exact schema marks the field optional and the event remains valid without it. Test omission and empty-array behavior separately because serializers can produce different requests.
Should TOO_FEW_ELEMENTS be retried?
Not until the data or mapping changes. It is a validation problem, so an identical retry is unlikely to help. Quarantine the record, preserve the reason, correct the source or builder, and deduplicate the later upload.
When HandL WP should help
HandL WP should help when WordPress leads or WooCommerce events fail after filtering leaves a required collection empty. We can instrument the builder, protect personal data, add boundary validation, and reconcile accepted and quarantined records.
If this is active on a production site, fix Data Manager API validation.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references