Skip to Main Content
Customer Feedback

We love feedback from you on our products and the problems in your daily work that you would like us to solve. Please describe the challenge you're encountering and your desired outcome. Be as detailed as possible.

For technical issues or bugs please head to Support or our Developer Community. You can assign up to 20 votes in total. Thank you for your feedback.

Status explanation: 'Future Consideration' = Continuing to collect further feedback, not planned at this time. 'Investigating' = Prioritized for deeper customer and feasibility investigations ahead of planning development.

Status Shipped
Product Campaign
Created by Guest
Created on Jan 19, 2021

webhooks for suppression events (unsubscribe / bounce)

Goals

  • we receive response- & interaction-data within seconds

  • we process suppression events (unsubscribe, spam-complaint, bounces) close to real-time

  • we replace existing response export-jobs

    • as currently used for closed loop interface (kms)

    • as used to provide data for our datalake / big query

  • with webhooks we can process response data immediately in order to trigger subsequent steps - e.g.

    • customer master data updates

    • re-calculation of next best offer / next best action

    • trigger for follow up communication within the same or an alternate communication channel

Background and strategic fit

  • event-driven communication has increased through the last years and became the key-driver for more relevance and personalization in CRM strategies

  • event based communication and decision making requires interaction data to be available near real-time

  • all communication channels need to deliver interaction data near real-time to fuel customer profiling and allow consistence communication across all channels

Requirements

standard payload included in all webhook events

  • mailing group ID (client- / mandator-ID)

  • mailing ID

  • encoded mailing2userID (mailId)

  • recipient ID

  • recipient list ID

#

name

event / usecase

payload

1

webhook for unsubscribe event

event sent in case a recipient withdraws email marketing permission via visible unsubscribe link or list unsubscribe header

usecase: the IP-address & user agent (http header) allow us to identify bots / spam-filters accessing unsubscribe-links

data to be included:

  • IP-address & http user agent (not for list unsubscribe header method)

2

webhook for bounce event

event sent for each failed message delivery attempt (hard-bounce / final soft-bounce)

data to be included:

  • bounce-category (hard- / soft-bounce)

  • error message

  • smtp error code

  • rule-name (indication if bounce reason is "spam related")

3

enhanced webhook for unsubscribe event - "nice to have"

event sent in case a recipient withdraws email marketing permission via visible unsubscribe link or list unsubscribe header - with additional data in payload

usecase: we need to calculate the number of unsubscribers who have used the visible opt-out link and reached our landing page where our survey for unsubscribe reasons is shown. This allows us to calculate the answer-rate of our survey.

additional data to be included:

  • unsubscribe method (http-LUH vs. smtp-LUH vs. visible unsubscribe link in text- / html-part)

4

webhook for "outbounced" event - "nice to have"

event sent for each recipient who reaches the status "outbounced" (maximum number of failed delivery attempts)

usecase: our routing-mechanism needs to be aware which email-addresses have reached the blocking-status "outbounced" and can not be reached with Episerver Campaign

data to be included:

  • exceeded bounce-limit (soft- / hard-bounce limit)

  • bounce counts for soft- & hard-bounce

  • Guest
    Reply
    |
    Mar 10, 2021

    Hello,

    as the information smtp error code and bounce message are of interest in more use cases than just webhooks, this will be implemented via API retrieval.

  • Guest
    Reply
    |
    Feb 10, 2021

    Yes, that would be a valuable addition.

    Regarding the "outbounced" event (aka threshold exceeded): Could this info be part of the payload in the bounce event?

    Regards.