Document toolboxDocument toolbox

Publishing Services stance 2017-06-29

Dear all,

 

To address the growing concerns about the looming enforcement of the Canadian Anti-Spam Legislation (CASL), Tracey Crawford and I have prepared the information below outlining the items that Publishing Services has done and will do from a systems perspective to navigate these new waters.

 

You will also be receiving or have already received the numbers of your active Canadian customers for each of your free list codes so that you can have an idea of the potential impact to your business.

 

Publishing Services has received feedback from some affiliates that they feel that Publishing Services owns the burden of ensuring that our clients are in compliance with the laws such as CAN-SPAM, GDPR, and CASL. We will definitely take this feedback into consideration and will share it with the Legal team and Management team. Up to this point, Publishing Services has operated in the mode of recommending best practices, and I should have done more to promote the best practices of handling CASL. I see where I’ve let some of you down in providing technical recommendations to navigate the CASL laws and I will be sure to remedy this in the future. Please know that Publishing Services has developed tools and features to assist in staying compliant with CASL, as you will read below.

 

Explanation of the law and any related legal guidance will officially come from the Legal department.

 

Functionality that is currently available in the Publishing Services systems to help you capture, target, and identify Canadian customers

 

(1)    Capturing address during order taking and lead generation

  1. OPIUM and Advantage

                                                               i.      When taking orders, both OPIUM and Advantage have fields to collect customer address and shipping address; this information is then stored in Advantage

  1. SignupApp 1, SignupApp 2, and IRIS Lead Gen

                                                               i.      When collecting names via Lead Gen forms, customers are often not asked for postal address nor do they provide when asked. To assist with these ‘email-only’ signups, the forms generated by SignupApp 1, SignupApp 2, and IRIS Lead Gen are designed to collect the IP address of the computer where the lead was submitted. This IP address is processed along with the email address, list code, and source code by Middleware is described next.

  1. Middleware

                                                               i.      Add Customer Signup — Add a customer signup to a list. POST list/customersignup/add

  1. Leads collected by SignupApp 1, SignupApp 2, and IRIS Lead Gen are processed using the Add Customer Signup calls in Middleware; we pass in the IP address in the header of the call to perform the Geo-Location lookup which often provides us with country and other address parameters; this information is stored in Advantage
  2. If you are using a Lead Generation tool outside of those offered by Publishing Services and are successfully collecting the IP address of the submitter, you will be able to successfully use these same Middleware calls to perform the Geo-location lookup

(2)    Targeting Canadian customers via emails

  1. Message Central

                                                               i.      The Customer Postal Address table from Advantage is available when creating Message Central SQL targets: WHERE relational.cdsadr_m.cun_typ = ‘CAN’; if you require assistance getting started, please submit a Jira Service Desk ticket so that one of our support agents can provide you with an example to follow

                                                             ii.      Technical Note: Message Central clicks and opens are also recorded with IP address, but the IP address currently being collected is that of an internal load balancer. This is not something that can be fixed in the Message Central application, but is something that was addressed with AMP.

(3)    Checking whether or not a customer is Canadian

  1. Middleware

                                                               i.      Get Geo-Location By IP Address — Find the geo-location of the customer based on the customer’s IP address. GET location/ipaddress/{ipAddress}

  1. If have a customer’s IP address and want to determine what country they are in, you can use this Middleware call; a good use of this call would be on your website

                                                             ii.      The Middleware calls below will return you the country code that is stored in Advantage

  1. Get All Data By Customer Number — Find all paid and demographic data by customer number. URL: GET data/plus/customernumber/{customerNumber}
  2. Get All Data By User Name and Password — Find all paid and demographic data using the customer’s username and password. URL: GET data/username/{base64encodeduserName}/password/{base64encodedpassword}. The countryCode for United States is denoted with a blank space/null value
  3. Get Postal Address By Customer Number — Get the customer’s postal address and other demographic information using their customer number. GET postaladdress/customernumber/{customerNumber}
  4. Get Postal Address By Email Address — Get the customer’s postal address and other demographic information using their email address. GET postaladdress/emailaddress/{emailAddress}
  5. Get Postal Address By Phone Number — Get the customer’s postal address and other demographic information using their phone number. GET postaladdress/phonenumber/{phoneNumber}
  6. Advantage UI

                                                               i.      The Customer screen in Advantage will allows you to see any captured postal addresses

 

Manual functionality that can be utilized to remove your Canadian customers

(1)    List cleaning of Canadian customers as recorded in Advantage can be manually cleaned off your list; we can couple the Canadian criteria with additional criteria as you see fit, but please take direction from our Legal team; these requests can be submitted as Jira Service Desk tickets

 

Automatic functionality that we have built but not yet turned on (awaiting go-ahead from our Legal team)

(1)    Process to remove any Canadian email addresses that have been recently added to free lists without a source code beginning with ‘x’; Publishing Services feels that this process will account for those email addresses that are swept onto free lists through Advantage premium sets; this will also remove those email addresses who were co-registered via an OPIUM order form

 

Some possible methods to capture explicit opt-in for Canadian customers

(1)    Email targeting Canadian customers asking them to ‘click’ if they would like to continue getting emails

  1. Build target in MC identifying Canadian customers
  2. Send email to Canadian customers asking them to click on a link
  3. Submit a Jira Service Desk ticket to ask for the export for raw clicks for that mailing six days after the mailing went out
  4. Affiliate to store that export of data indefinitely

(2)    Email targeting Canadian customers asking them to sign up to the list again

  1. Build target in MC identifying Canadian customers
  2. Send email to Canadian customers asking to sign up again
  3. The sign up attempt will be stored in Advantage indefinitely

 

How we store signup data

(1)    SignupApp 1, SignupApp 2, and IRIS Lead Gen

  1. These applications are the first locations where signup information (IP address, email address, list code, and source code among other information) is collected and stored; this information is stored indefinitely

(2)    Middleware

  1. After being collected by either SignupApp 1, SignupApp 2, and IRIS Lead Gen, the signups are submitted to Middleware
  2. Middleware stores this information for only 2 weeks

(3)    Advantage

  1. Every signup attempt is stored in Advantage without IP address; the prominent data elements are signup attempt date, email address, list code, and source code

(4)    Note: The idea is that we should be able to trace our way back to the signup form used based on the source code used; one possible issue is that the signup forms themselves are not necessarily stored in a Publishing Services system; instead, they are often hosted on affiliate websites

 

Thanks,
Enrico


This was sent to the following people on 2017-06-29

U.S.

MMP – Katie Melchor, Brett Holmes, Danielle O’Dell, Kevin Dowdle

AF – Mike Pizzo, Shawn Lyttle, Chris Meyers, Jon Kissane, Katie Vogel

NMH – Amanda Fowler-Haughwout, Melissa Young, Erin Beale

Oxford – George Rayburn, Laura Cadden, Chris Witmer

INH – Ambar Jones, Scott Hogan, Angela Jirau

Legacy – David Dittman, Amber Mason, Fernando Cruz

Banyan Hill and Dent Research  – Amanda Goss

Tradesmith – Alison Kirton, Taryn Jacobson

OmniVista – Brian O’Connor, Karen Reddel

 

International

SNI – Olivier Chabanel, Lukas Menal

Nova – Capucine Colombet

IL – Emer Purcell

Port Phillip – Vince King, Kris Sayce

AFAU – James Woodburn

PAF – Catherine Dourlens

Southbank Research – Gabe Kushner

Agora Financial UK – Darren Hughes, Matt Allinson, Bea Morrissey

Agora Health UK – Pippa Ashman, Emma Gowdie

IG Spain – Pablo Abbate, Alberto Redondo

IG Chile – Felipe Ramirez, Hernan Cieri

Global Publishers – Fernando Robles

Equity Master – Deepak Rajpal

China – Greg Gau

Portner Press – Rebecca Low, Pippa McKee


com.atlassian.confluence.content.render.xhtml.migration.exceptions.UnknownMacroMigrationException: The macro 'html-macro' is unknown.