Automated Responses in Marketing Suite

We have been dealing with a number of issues in relation to the auto response allocation process in Marketing Suite. This has ranged from source codes with 10 targets showing 200 responses, to entire campaigns where no response data being recorded. In trying to analyse the issues, a number of things have become apparent:

There does not appear to be any documentation that provides any detail on how the automated response processing is intended to work.
None of the specific rules for finding and attributing responses are defined anywhere
There is no audit trail to be able to trace back from a response to the transaction that was attributed to that response

Can anyone provide any more detail on the workings of this feature to enable us to determine if it is working correctly and to explain to customers what they are seeing and why they are seeing it?

As an interim measure, we have create our own functionality in AP for assigning source codes to transactions based on a combination of appeal participation, product and transaction data. This has included the creation of an audit table that we can reference to see what transaction has been assigned to what source code and 2 stored procs - 1 to update the data in the link table and 1 to update the trans table with the source code values. These are attached.

I would also appreciate any feedback on these. Are the rules correct? And how could we add the management of unsolicited responses, which we have chosen to exclude at this stage.

AttachmentSize
sp_UpdateTransData.sql738 bytes
sp_UpdateResponseHoldingTable.sql2.48 KB
CampaignParticipationSource.sql768 bytes

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Jumping in to the deep end on response management

Hi Mick -

I usually try to stay in the wading area of the iMIS pool, but I did just write up some documentation surrounding how opt-out responses work for marketing campaigns, so I'll try to provide some detail from that topic which will be published to docs.imis.com soon. It doesn't specifically spell out rules, nor does it give you an audit trail, but it's a start towards additional detail on the intended behavior.

Based on your questions, I'd like to keep improving this topic with additional information. Once I figure out the whole swimming thing. :) Please give me your feedback.

 

Understanding opt-out configuration

Sometimes people want to be removed from a campaign mailing list. This action is called opting out. Campaign managers want to know the number of people who opt out of a campaign and which source code is related to the opt-out action.

Understanding the tracking of opt-outs helps you analyze the campaign's effectiveness. Opt-outs are tracked from the originating source code so that your campaign manager knows the source code that caused the opt-out action.

Two settings and inserting code into an email template control the opt out configuration:

  • Marketing > Set up module > Opt Out Url field points to a special opt out page, such as http://www.domainname.org/imis15/OptOut.aspx. When the person clicks on the link in the email containing the Opt Out code, they are taken to this page. The page can contain instructions for choosing to be removed from the list, or request further information for why the message caused the email recipient to choose to be removed.
  • Marketing > Set up module> Opt Out Key field contains %OPTOUTURL% by default. This field contains the code that you insert into the email tempate in the HTML code. You could change it to %REMOVEME% or another variable name, but you must be sure to change the code in the email templates that use the Opt Out Key in them.

When you create an email merge template, use HTML, not plain text, and use %OPTOUTURL% for the URL for the link. For example, add the text, "If you want to be removed from our campaign, click here." Highlight "click here" and insert a link. Enter %OPTOUTURL% as the URL and choose Other as the Type.

Using this email merge, generate output from a source code. The email messages are generated and sent.

When an email recipient clicks the "click here" link in the campaign email, they go to the URL for the Opt Out Url page configured in iMIS Marketing > Set up module.

If you have more than one source code in one campaign that solicits the same prospect, opting-out for any one source code should opt-out all source codes in the campaign that have solicited that prospect. In addition, iMIS discontinues all further campaign appeals, solicitations, and source codes for that prospect, even those that are created after the opt-out. In short, any future lists automatically exclude that contact from being selected again.

For example, when you look at the Record Responses area and look up an ID, you see every source code they are being solicited for. If a member is solicited by two different source codes within the same campaign, they are shown as opted-out of both campaigns.

Are there any options for single opt outs?

Are there any options for opting out of a single Campaign, instead of all of them? (Or even based on Solicitation, instead of Campaign)?

Example:
The Red Cross has many different Campaigns, Appeals, and Solicitations.

A donor gets a solicitation on blood drives, but isn't insterested and wants to opt out. Under the current programming, this would mean they would be opted out of all campaigns, but what if that same donor was interested in "disaster relief" campaigns, like contributing to Gustav aid/relief funding?

This is only one example. Universal opt outs should always be an option, but campaign-specific, appeal-specific, or even solicitation-specific opt outs need to be a possibility as well.

Currently, it's like asking "Do you like pepperoni pizza?" getting the response, "No, I'm a vegetarian," and taking only the "No" as a reason to never speak to them again, even though you have a stack of amazing veggie supreme or margherita pizzas ready to go.

-K

Kevin Blouin - enSYNC Corp.

Great analogy

Love the pizza analogy. Unfortunately, we don't currently have a single campaign (or appeal or solicitation) opt-out. From the doc: "If you have more than one source code in one campaign that solicits the same prospect, opting-out for any one source code should opt-out all source codes in the campaign that have solicited that prospect. Here's the universal part - In addition, iMIS discontinues all further campaign appeals, solicitations, and source codes for that prospect, even those that are created after the opt-out. In short, any future lists automatically exclude that contact from being selected again."

You have great examples for why this implementation needs some work. Have you submitted an RSE? I can do so if you need me to.
Thanks,
Anne

It is not a current RSE

I haven't yet submitted this. I wanted to get more feedback from the community before pushing it up. If you would like to send this up the chain, please do so.

-K

Kevin Blouin - enSYNC Corp.

Thanks and looking forward to more

Thanks for the info of Opt outs Anne.

We are really trying to find out as much as we can about the "black-box" of response allocation, so anything helps.

Are you also working on how the automated response tracking works and documenting this? If so, I think some examples would be great. To look at starting with a single product/ appeal / solicitation / source code for 100 targets say and identify how each of the groups are compiled in terms of solicited and non-solicited responses and non-responses.

If we could then break out to more significant examples, that would be great - multiple appeals, multiple products, multiple source codes, etc.