Propose new Mautic features

What are the options for better bounce management and what we can do to push this forward? I would like to create concrete issues that I can use to guide to implement new functionality.

What are the ambitions I have heard/read about?

1. Add complaint flag to DNC
2. DNC flags cover that cover all cases with double opt-in

My idea: Lets not bother with getting every possible flag in the core, but rather extend DNC in Mautic core in a way that plugins can add new flags appropriate to transport (this is not without concerns but I believe if we do it right, this can be really powerful).

Notes (credit to Joey):

We need a good solution for all flags to cover all cases with DOUBLE OPTIN / DNC / COMPLAINT

• Can I send email at all?
• Can I send marketing email?
• Can I send email still at all? :)
• Did I send email altough I shouldn't have?

THINKING ABOUT THE PROBLEM

Data into DNC tables comes from Amazon SES, Mailgun, Omnivery, etc., it also can come from Mautic (import of contacts or manual unsubscribe). If transport plugins are the ones that are importing the data into database, why not delegate the interpretation of those records to the plugins as well.

TOPIC: Complaint flag

- At the moment DoNotContact entity does not support tracking of complaint/soft bounce, we need to enable that.

- Extending current entity by just adding another constant and using the same architecture is not wise on the long run in my opinion we need a better entity (db table that stores that data).

TOPIC: Extension of DoNotConctact entity (lead_donotcontact table)

- I would like to deprecated reason property. And add the following properties into DNC table: reasonCode – string (examples: IS_CONTACTABLE, UNSUBSCRIBED, BOUNCED, MANUAL, etc.), origin – string (mautic_core, transport_plugin_mailgun, etc.).

- Data would come from at least two sources into this table – from Mautic core and transport plugins.

- There can also be additional properties but I think the above two are the most important.

TOPIC: Need to allow transport plugins to inject logic in parts of the core

- Instead of using hardcoded constants in the core code I would dispatch an event each time we need to decide if something needs sending or not. Event could have flag like canSend, which subscribers to that event would then set and at the end the core code would check the flag and do the appropriate logic accordingly.

- With this approach I think we get certain level of maintainability because if in the future new flag comes we only need to adjust the logic in subscribers as oppose to the entire core code.

- As I see it at least two subscribers would be required with the typical implementation – one in Mautic core and the other with the transport plugin.

- This solves the checks in the code, but does not solve the displaying statistics (to get solution for this, please keep reading – Display Statistics in GUI).

- We can support multiple transports on one Mautic instance by making subscribers process only the records of its own source/origin

- Side note: Mautic subscribers to that event should execute last (I cannot really explain why at the moment, it just feels right).

TOPIC: Double opt-in

(just mentioned, I have looked into the topic)

There is a plugin that solves the double opt in: https://github.com/content-optimizer-gmbh/mautic-doi-plugin

In terms of solving this on the core level, this is how I would do it (this was the first thought after I read about DIO in detail):

- Each time contact is added into Mautic it gets a flag: NO_DOUBLE_OPT_IN

- When contact confirms it, we change the reasonCode to IS_CONTACTABLE

- The subscribers to events then based on the reasonCode tell us, if the email/sms or something else should be sent or not.

TOPIC: Display Statistics in GUI

(not mentioned on the meeting, but I thought about it while writing the notes)

- If we use the event/subscriber approach I can see we will have difficult times displaying any kind of statistics in GUI, that is because values in DNC table will be different for each transport

- To tackle that I suggest that we allow users in Mautic to create groups (subscribed, bounced, etc.) and then define the rules that tell Mautic how it should map records from DNC table following certain patterns.

QUESTIONS:

1. Can I ask fellow developers and other experts on the matter to take a look and see if I can get anywhere with event/subscriber approach?

2. Is there a potential for performance issues due to dispatching events every time we need to decide if something should be sent or not?

Looking forward to the feedback. Thanks.

RECORDING: https://drive.google.com/drive/folders/18rJffzWXxoUT7Tuamlr8lS_zRxRgFPTR?usp=drive_link