Product ideas | Community
Skip to main content

Ideas

Filter by idea status

10000+ Ideas

2step opt-out process for email unsubscribersInvestigating

Why is this feature important to you?Loosing email subscribers is a threat to every marketing program. This is why we should assure opt-out requests are gathered where recipients actually still like to receive emails. But this happens when content filters / spam filters analyze URLs in our emails. They need to "click" every link in order to analyze where the link redirects to and if it leads to a landingpage which is potentially dangerous. As this may be done for all URLs within our emails this affects unsubscribe links as well. Unfortunately this leads to automated "bot clicks" causing unsubscribed email recipients which have to be excluded from further email campaigns. We must avoid this happens with email subscribers who actually still like to receive our content.  How would you like the feature to work?Of cause a 2step opt-out process is  a solution to solve this problem. However we need to make sure that unsubscribers which were gathered via 2step opt-out process are still counted within context of a campaign. This is needed in order to calculate unsubscribe rates on campaign-level. If unsubscribers from 2step-process are not counted / attributed for the campaign / email from where the unsubscribe link was used then the unsubscribe rates of campaigns would be incorrect. It would be way too low as it would only count unsubscribers which were gathered via list unsubscribe header. So there would be an opt-out rate - but it would be incorrect / to low. That would be worse than having reporting with no opt-out rate at all because an incorrect rate would be misleading for most users. Current Behaviour?The API where we can ingest unsubscribers from the 2step opt-out process does not reflect the campaign which was unsubscribed. Therefore unsubscribed email addresses are gathered without connection to a campaign. This results in the mentioned problem / incorrect unsubscribe rates on campaign-level.

LuGebNew Member

Object access control inheritance through folders or automatic assignment by current user groupsInvestigating

Description: I am looking for ways to enable data segregation within a sandbox, allowing different teams to have access to different objects such as journeys, campaigns, etc. The goal is to avoid the cumbersome process of manually assigning labels after objects are created to ensure that only relevant roles can see specific labels. Alternatively, having folder level access control where objects inside such folders will inherit access control restrictions would be beneficial.  Why is this feature important to you: This feature is important because it streamlines the process of data segregation, ensuring that teams can efficiently manage and access their respective objects without the need for manual label assignments. It enhances security and organization by automatically restricting access based on roles. How would you like the feature to work: I would like the feature to automatically assign labels to all objects created by certain roles, ensuring that only users with those roles can see these objects. Alternatively, folder level control with cascading permissions for objects within the folder, with folder-level label assignments being respected for all entities within those folders. Current Behaviour: Currently, labels must be manually assigned to objects after they are created, which is cumbersome and inefficient. This manual process is required to ensure that objects are visible only to users with specific roles who can see the assigned labels.

georgeisar
georgeisarLevel 2

Enable Flexible Placement of Tracking Pixel in EmailsInvestigating

Description:Introduce functionality to allow users to choose the placement of the tracking pixel, either at the top or bottom of emails, directly through the UI interface. This feature would enhance tracking accuracy and improve the overall user experience. Why is this feature important to you:The current placement of the tracking pixel at the bottom of emails limits the accuracy and speed of engagement tracking. Allowing placement at the top would address key challenges, including missed opens from recipients who don’t scroll through the email, delayed pixel loading in heavy-content emails, and inconsistencies across devices and email clients.Allowing the user to place the tracking pixel to the top of the email could bring several benefits, and we wanted to share why we believe this enhancement would add value: 1. Faster Engagement Tracking: A top-placed pixel activates as soon as the email is opened, providing immediate and accurate open-rate data. 2. Improved Metrics Reliability: Reduces the risk of missing opens from recipients who don’t scroll through the entire email. 3. Optimized User Experience: Ensures tracking accuracy even in emails with heavier content that might delay full loading. 4. Device and Client Consistency: Makes tracking more reliable across different email clients and devices, including those that truncate or partially load emails. How would you like the feature to work:The UI should include a simple option to select the desired tracking pixel placement (top or bottom). The system should automatically adjust the email structure to ensure proper pixel functionality, providing flexibility to suit diverse use cases. Current Behaviour:Currently, the tracking pixel is fixed at the bottom of emails, causing delays in engagement tracking, inaccuracies in open-rate data, and reduced reliability across different devices and email clients. This limitation impacts the effectiveness of performance insights and optimization efforts.

SorenDPLevel 4

Simulate content in transactional email campaign - With contextual dataInvestigating

DescriptionWhen setting up transactional campaigns for sending out transactional emails containing contextual data, it is currently not possible to simulate the email with contextual data. That means that if a receipt is made up from contextual data points, we will have to simulate the final email by sending in API calls. That is an issue when changing something in an email that is already live, since our only option to test it is to then hope for the best, set it live and see how it looks. Instead we "could" copy the campaign to test an entirely new campaign, but that seems kind of overkill if we are simply aiming to making small adjustments to the live receipt.  Why is this feature important to youThe workflow of making changes to a live transactional email with contextual data and testing those changes is very heavy and time consuming. How would you like the feature to workWould like to be able to modify an existing live transactional campaign containing contextual data and simulate the email including contextual data points. 4 Current BehaviourCurrently not possible. I can only simulate the content from a test profile but not include any contextual parameters. Only option today is either duplicating the campaign -> make the changes -> -> send in test API calls to see if the contextual data behaves and the entirety of the email.