Duplicate Leads Issue Resolution
Budget: $10 – $30 USD
[We have fix now , bid only if you are available for work]
We have website with landing pages and user filled leads over there.
Leads going through make.com setup
issue is one leads going multiple times at one time.
Means user filled leads and its showing multiple time same leads at our end.
Reply Suggestion from team :
I have taken a close look at the executions you referenced and the root issue is that the sending service is sneding multiple payloads for the same record.]] Here is a screenshot that compares the logs of the payloads that were sent to Make:
In the screenshot above, it is visible that although the "body" is the same, the payloads are different in Headers. You can find these logs here: https://eu2.make.com/1490634/hooks/2677580/logs
To summarize, you need to check with the sending service to understand why multiple payloads are being sent for the same record
Screeshot : https://prnt.sc/HepCW1JJgvJu
------
Here's a breakdown of how to debug this issue, assuming "sending service" refers to the form on your landing page and how it sends data to Make:
*Understanding the Problem: Why would the landing page send multiple payloads?*
The most common reasons a landing page form sends duplicate submissions are:
1. *User Double-Clicks/Multiple Submissions:*
* A user clicks the submit button multiple times rapidly.
* The user refreshes the "Thank You" page, causing a re-submission.
* The user navigates back and then forward in their browser, triggering a re-submission.
2. *Client-Side (JavaScript) Issues:*
* JavaScript code might be accidentally submitting the form more than once. This could be due to event listeners firing multiple times, or incorrect AJAX calls.
* Form validation might be re-triggering submissions.
3. *Server-Side Issues (less common for direct form-to-webhook):*
* If there's a backend script processing the form before sending to Make, that script could have a bug causing it to send multiple webhook requests.
4. *Network/Browser Behavior:*
* In rare cases, if a browser doesn't receive an immediate 200 OK response from the webhook, it might try to resend the request.
*Debugging Steps (Focusing on the Landing Page and Form):*
Given the URL you provided, https://gadgetsaleshub.com/wall-heater-es/?gad_source=1&gad_campaignid=22630960062&gclid=Cj0KCQjwmqPDBhCAARIsADorxIbX8lzHmfysKWN3B0UY7p1uq3h8bGF3ZYb-RwcrWXdjULvsW9y-gEUaAnY6EALw_wcB#prezzo, it looks like a standard landing page.
1. *Inspect the Landing Page Form (Developer Tools):*
* *Open your browser's Developer Tools (F12 or right-click -\> Inspect Element) on the landing page.*
* *Go to the "Network" tab.*
* *Clear the network log.*
* *Fill out the form and submit it.*
* *Immediately observe the network requests.*
* Are you seeing multiple POST requests to your Make webhook URL for a single form submission?
* If so, what are the response codes for these requests? (Ideally, Make should send a 200 OK immediately).
* Check the timing of these requests. Are they happening milliseconds apart?
2. *Check Form Submission JavaScript:*
* *Go to the "Elements" tab in Developer Tools.*
* *Inspect the form element (<form>) and the submit button (<input type="submit"> or <button type="submit">).*
* Look for onclick or onsubmit attributes, or any JavaScript event listeners attached to them. This will likely require digging into the associated JavaScript files in the "Sources" tab.
* *Common JavaScript fixes:*
* *Disable the submit button after the first click:* This is a crucial client-side prevention.
javascript
document.getElementById('yourFormId').addEventListener('submit', function() {
document.getElementById('yourSubmitButtonId').disabled = true;
// You might also want to change its text to "Submitting..."
});
* *Prevent default submission if using AJAX:* If your form uses AJAX, ensure event.preventDefault() is called to stop the browser's default form submission behavior, which can often lead to duplicates if not handled correctly.
javascript
document.getElementById('yourFormId').addEventListener('submit', function(event) {
event.preventDefault(); // Stop default form submission
document.getElementById('yourSubmitButtonId').disabled = true;
// Your AJAX call here
});
* *Ensure AJAX success/error handling:* Make sure your AJAX success callback properly handles the response and doesn't re-trigger anything.
3. *Review the Landing Page Platform/Builder Settings:*
* If you're using a landing page builder (e.g., Leadpages, Unbounce, Instapage, or a WordPress plugin like Elementor, Thrive Architect, etc.), check its form settings.
* Look for options related to:
* *Duplicate submission prevention.*
* *Redirect after submission:* Often, redirecting to a dedicated "Thank You" page helps prevent browser refreshes from re-submitting the form.
* *AJAX submission settings.*
4. *Implement Idempotency in Make.com (as a secondary defense):*
While the root cause is the sending service, Make.com can be configured to ignore duplicates based on a unique identifier if the sending service provides one.
* *Identify a Unique Identifier:* Look for a field in the webhook payload that would be unique to a single submission (e.g., an order_id, submission_id, email + timestamp combination, or a generated UUID).
* *Use a Data Store or Google Sheet in Make:*
* *Scenario Flow:*
1. *Webhook Trigger*
2. *Search Records (Data Store or Google Sheet):* Search for the unique identifier.
3. *Filter:* If the unique identifier already exists in your storage, terminate the scenario.
4. *Add Record (Data Store or Google Sheet):* If it doesn't exist, add the unique identifier to your storage.
5. *Continue with the rest of your scenario.*
* *Example (Conceptual Make Modules):*
* Webhook -\>
* Make Data Store - Search Records (Search for unique_id from webhook) -\>
* *Filter:* Condition: {{search_records_module.found_items_count}} > 0 (If items found, stop scenario) -\>
* Make Data Store - Add Record (Add the unique_id to your data store) -\>
* Your Original Modules (e.g., CRM module, Google Sheets module)
*Summary of Debugging Focus:*
The "sending service is sending multiple payloads" statement is key. Your debugging efforts should primarily focus on:
1. *The client-side (JavaScript) of your landing page form.*
2. *The configuration of your landing page builder/platform's form.*
3. *Network requests as observed in browser developer tools.*
Once you identify why the landing page is sending multiple payloads, you can implement the appropriate fix on the landing page itself. The Make.com idempotency strategy serves as a robust fallback to catch any duplicates that might still slip through.
We have website with landing pages and user filled leads over there.
Leads going through make.com setup
issue is one leads going multiple times at one time.
Means user filled leads and its showing multiple time same leads at our end.
Reply Suggestion from team :
I have taken a close look at the executions you referenced and the root issue is that the sending service is sneding multiple payloads for the same record.]] Here is a screenshot that compares the logs of the payloads that were sent to Make:
In the screenshot above, it is visible that although the "body" is the same, the payloads are different in Headers. You can find these logs here: https://eu2.make.com/1490634/hooks/2677580/logs
To summarize, you need to check with the sending service to understand why multiple payloads are being sent for the same record
Screeshot : https://prnt.sc/HepCW1JJgvJu
------
Here's a breakdown of how to debug this issue, assuming "sending service" refers to the form on your landing page and how it sends data to Make:
*Understanding the Problem: Why would the landing page send multiple payloads?*
The most common reasons a landing page form sends duplicate submissions are:
1. *User Double-Clicks/Multiple Submissions:*
* A user clicks the submit button multiple times rapidly.
* The user refreshes the "Thank You" page, causing a re-submission.
* The user navigates back and then forward in their browser, triggering a re-submission.
2. *Client-Side (JavaScript) Issues:*
* JavaScript code might be accidentally submitting the form more than once. This could be due to event listeners firing multiple times, or incorrect AJAX calls.
* Form validation might be re-triggering submissions.
3. *Server-Side Issues (less common for direct form-to-webhook):*
* If there's a backend script processing the form before sending to Make, that script could have a bug causing it to send multiple webhook requests.
4. *Network/Browser Behavior:*
* In rare cases, if a browser doesn't receive an immediate 200 OK response from the webhook, it might try to resend the request.
*Debugging Steps (Focusing on the Landing Page and Form):*
Given the URL you provided, https://gadgetsaleshub.com/wall-heater-es/?gad_source=1&gad_campaignid=22630960062&gclid=Cj0KCQjwmqPDBhCAARIsADorxIbX8lzHmfysKWN3B0UY7p1uq3h8bGF3ZYb-RwcrWXdjULvsW9y-gEUaAnY6EALw_wcB#prezzo, it looks like a standard landing page.
1. *Inspect the Landing Page Form (Developer Tools):*
* *Open your browser's Developer Tools (F12 or right-click -\> Inspect Element) on the landing page.*
* *Go to the "Network" tab.*
* *Clear the network log.*
* *Fill out the form and submit it.*
* *Immediately observe the network requests.*
* Are you seeing multiple POST requests to your Make webhook URL for a single form submission?
* If so, what are the response codes for these requests? (Ideally, Make should send a 200 OK immediately).
* Check the timing of these requests. Are they happening milliseconds apart?
2. *Check Form Submission JavaScript:*
* *Go to the "Elements" tab in Developer Tools.*
* *Inspect the form element (<form>) and the submit button (<input type="submit"> or <button type="submit">).*
* Look for onclick or onsubmit attributes, or any JavaScript event listeners attached to them. This will likely require digging into the associated JavaScript files in the "Sources" tab.
* *Common JavaScript fixes:*
* *Disable the submit button after the first click:* This is a crucial client-side prevention.
javascript
document.getElementById('yourFormId').addEventListener('submit', function() {
document.getElementById('yourSubmitButtonId').disabled = true;
// You might also want to change its text to "Submitting..."
});
* *Prevent default submission if using AJAX:* If your form uses AJAX, ensure event.preventDefault() is called to stop the browser's default form submission behavior, which can often lead to duplicates if not handled correctly.
javascript
document.getElementById('yourFormId').addEventListener('submit', function(event) {
event.preventDefault(); // Stop default form submission
document.getElementById('yourSubmitButtonId').disabled = true;
// Your AJAX call here
});
* *Ensure AJAX success/error handling:* Make sure your AJAX success callback properly handles the response and doesn't re-trigger anything.
3. *Review the Landing Page Platform/Builder Settings:*
* If you're using a landing page builder (e.g., Leadpages, Unbounce, Instapage, or a WordPress plugin like Elementor, Thrive Architect, etc.), check its form settings.
* Look for options related to:
* *Duplicate submission prevention.*
* *Redirect after submission:* Often, redirecting to a dedicated "Thank You" page helps prevent browser refreshes from re-submitting the form.
* *AJAX submission settings.*
4. *Implement Idempotency in Make.com (as a secondary defense):*
While the root cause is the sending service, Make.com can be configured to ignore duplicates based on a unique identifier if the sending service provides one.
* *Identify a Unique Identifier:* Look for a field in the webhook payload that would be unique to a single submission (e.g., an order_id, submission_id, email + timestamp combination, or a generated UUID).
* *Use a Data Store or Google Sheet in Make:*
* *Scenario Flow:*
1. *Webhook Trigger*
2. *Search Records (Data Store or Google Sheet):* Search for the unique identifier.
3. *Filter:* If the unique identifier already exists in your storage, terminate the scenario.
4. *Add Record (Data Store or Google Sheet):* If it doesn't exist, add the unique identifier to your storage.
5. *Continue with the rest of your scenario.*
* *Example (Conceptual Make Modules):*
* Webhook -\>
* Make Data Store - Search Records (Search for unique_id from webhook) -\>
* *Filter:* Condition: {{search_records_module.found_items_count}} > 0 (If items found, stop scenario) -\>
* Make Data Store - Add Record (Add the unique_id to your data store) -\>
* Your Original Modules (e.g., CRM module, Google Sheets module)
*Summary of Debugging Focus:*
The "sending service is sending multiple payloads" statement is key. Your debugging efforts should primarily focus on:
1. *The client-side (JavaScript) of your landing page form.*
2. *The configuration of your landing page builder/platform's form.*
3. *Network requests as observed in browser developer tools.*
Once you identify why the landing page is sending multiple payloads, you can implement the appropriate fix on the landing page itself. The Make.com idempotency strategy serves as a robust fallback to catch any duplicates that might still slip through.