PipedreamHQ / PipedreamHQ/pipedream
google_ads: adding a contact to a customer list uses three API calls and skips email normalization
- Dominant language
- JavaScript
- Stars
- 11.7k
- Forks
- 5.8k
- Avg merge
- 3d 10h
- Merged PRs (30d)
- 102
Description
## Problem
1. Add Contact to Customer List by Email creates a new offline user data job, adds one identifier to it, then runs the job. That is three API calls for a single contact. A customer syncing a list in a loop spends three operations per contact, so a 1,000 contact sync uses 3,000 operations against a 15,000 daily limit.
2. Google's guidance is the opposite of this design. It recommends putting all operations into one job rather than creating many small ones, and suggests up to 10,000 identifiers in a single call.
3. The email is hashed without normalizing. Google requires trimming whitespace and converting to lowercase before hashing, plus removing dots and plus suffixes for Gmail addresses. The action hashes the raw input, so an address typed with different casing or spacing produces a hash that will not match. This does not raise an error. The action reports success and the contact silently fails to join the list.
## What's needed
- A way to add multiple contacts in one job.
- Emails normalized before they are hashed.
## Notes
- Normalization requirements and batching guidance: https://developers.google.com/google-ads/api/docs/remarketing/audience-segments/customer-match/get-started
- Point 3 is a correctness problem rather than a quota one. It is worth fixing even if the batching change is deferred.
- Context: quota exhaustion reported in #19945, #21509, #21554, #21782, #21926.
Contributor guide
Research direction
The issue does not name files or tests; start by locating the google_ads action that creates, populates, and runs offline user data jobs. Compare its request flow and email hashing with the linked Google Ads guidance. Done means contacts can be batched into one job and emails are normalized before hashing, with coverage for both behaviors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- backend-api-design
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100