I am not sure how to do that through the UI. You may be able to do this via some scripting and mysql
I thought it was the standard behaviour, because in this way I lose all the info about page hits, source of acquisition, etc
Hi! Is this a form filled out on a page or you are posting to a form via API?
Normally how do you track contact source, if for example the lead cames from advertising, than visits some pages and then submits a form?
Normally it goes like this:
If you have the tracking script in the website, mautic gives you a tracking cookie with the lead id.
Mautic starts recording page hits to this lead id.
If the user submits a contact form, the information will be written to the already known lead id.
So you should see the pagehits the use have done before the form submit.
I have a similar issue - described in this thread:
It seems, that anonymous contacts are not merged under certain circumstances as they supposed to. (logically…)
For example as in the thread described:
- anon user browse the page
- email added by API (at this point it should not be merged)
- new contact created
- welcome email sent out
- email opened, cookie found, contact NOT merged with prev anon contact.
I would love to see if this is expected behaviour.
Yes I expect this behaviour,
but this not works for me. Every contact starts with Contact created event (form submission). I don’t have any history before that
This sounds like a third party cookie problem. Check if your mautic domain is on the same root domain like the website you embedded the mautic form.
Is this the case?
Sorry missed your question if this is expected behaviour. Normally it should merge the contact but ONLY if the email is opened in the same browser he got the cookie from point 1.
In Point 1. the user should get a cookie with a lead id.
In Point 2 you create another lead id with the email.
In point 3. you send a welcome email (make sure you enabled track_by_tracking_url in the config) which got the lead id encoded in the email links.
If the visitor opens the email link in the same browser he got the cookie from (in point 1) mautic should merge the lead.
Hi, I layed out my issue here.
Person is browing on day 1 creating an anonimous contact. Then on day 5 he buys something, and a tracking pixel is fired up with the email value in it. (We get the email on the thank you page, so we can embed it into the pixel.) At the same time the shopify webhook pushes in the cart contents via API into Mautic using the email as unique identifier. What really happens is, that the tracking pixel is not connecting with the previous unknown visitor, but creating a new contact who already has the email and has never been on the website before.
I think THIS is how it should work:
I would agree with you. This should work.
What happens if you launch the command:
php app/console mautic:contacts:deduplicate
One more addition: these contacts have the same mautic device id, but not merged.
What does the dedupe look at?
I think the deduplication looks for the fields which are defined as unique values. Mautic default should be the email address.
Just to be sure: you got 2 leads both with the same email address?
I will have an anonymous contact with pre-purchase events, and a known contact with post purchase events and an email, both having the same Mautic Device ID.
Does that change anything?
For me actually I’m on a different domain respect to the website…I will make a test tracking if the mautic cookie is set after the first visit.
And I’m moving mautic on the same subdomain, so I can exclude this
I think mautic will not merge based on the device id.
But I’m a little bit confused:
In your flow chart you said you set the email address via the tracking pixel to contact 1?
Why is one lead anonymous? They should both have an email address?
I installed Mautic 3 in my same domain and checked track IP in the system configuration.
Now I can track the contact history also before he submits a contact form.
I don’t know if the problem was a different domain or Mautic version ( I still use 2.X in the other domain), but the issue seems resolved