Suggestion

[chowerton]

It would be nice if I could use this API to also build an Opt-In/Out list for an iOS App. There are lots of web-based systems for this, but none for native iOS apps. Fields would be: email, first name, last name, state (opt-in or opt-out).

[mattiaslevin]

Not sure if I fully understand. Do you mean like a "opt-in-for-newsletter" thingy?

I guess this information would be stored on a backend. Who would use this information and how?

Would be great if you could provide a simple use case.

mvh /Mattias

[chowerton]

Mattias: An excellent question. And, you have guessed correctly: it’s for a “opt-in-for-newsletter” thingy.

Here is the situation: Where I live (Canada), the government has introduced CASL — the Canadian Anti-Spam Law. It is not a bad idea at all: the idea is that companies in Canada need to have an explicit opt-in list before they can send newsletters or even eMails to potential customers. There are some exceptions, such as if the person you are sending an email to is an “active customer”. But the problem is: with an iOS App, how do you know if somebody is or is not an active customer (or even is a customer at all)?

In addition to needing the Opt-In to receive mailings or newsletter or any other form of communication, there is also the need to maintain an Opt-Out list.

Oh, and if a company is “nice”, they want to do double opt-in… with a confirmation via email typically.

Many companies who do emailing (such as MailChimp) have web API’s that make it easy to collect Opt-In/Out information for web services.  But I see nothing for native Apps.  

As you correctly state, this information (first name, last name, email, date, time, status: opt-in or opt-out) would need to be stored on a backend.  But most native App programmers are backend service programmers, so that’s easier said than done.  Hence, in my opinion this is ideal as a service.  And, since collecting this Opt-In/Opt-Out information is similar to collecting other “countable actions”, it made sense to me that it’s a potential enhancement for Piwik.  I know that I would be willing to pay a monthly fee to know that I have a customer list of who’s “in” and who’s “out”.

The argument from naysayers would be: just convey the information you want to convey from within your App.  Or they might say: just get them to sign up or not on your website.  To a certain extent, these suggestions are okay.  But having customers navigate to a completely different system to do this is inconvenient and many just would not bother.  And sometimes the information (such as having a reference manual with instructional videos, an area where people can share tips, etc.) is just not what you do within an App.

So that’s what I was thinking: you’re counting everything else, why not also count Opt-In and Opt-Out, and supply access to that list for a monthly fee.  It would save a ton of coding time.

Christopher Howerton

On Nov 24, 2014, at 11:36 PM, Mattias Levin notifications@github.com wrote:

Not sure if I fully understand. Do you mean like a "opt-in-for-newsletter" thingy?

I guess this information would be stored on a backend. Who would use this information and how?

Would be great if you could provide a simple use case.

mvh /Mattias

— Reply to this email directly or view it on GitHub https://github.com/piwik/piwik-sdk-ios/issues/56#issuecomment-64320559.

[mattiaslevin]

Thanks for the detailed explanation.

I do not think this feature should be implemented within the Piwik context. But I certainly understand the challenge you are describing.

I think this is a great idea for a separate project and since I double both as iOS and backend developer I can probably do all/most of the parts needed. I will ask some fiends at work if they like to help out. If so I will set up a separate Github project for this.

I guess we will need a backend, a web page for simple administration tasks and maybe a SDK for a couple of platforms.

Let me dwell on this a little more. I just need to wrap my head around the use case.

Cheers

[mattab]

as @mattiaslevin pointed out:

I think this is a great idea for a separate project and since I double both as iOS and backend developer I can probably do all/most of the parts needed. I will ask some fiends at work if they like to help out. If so I will set up a separate Github project for this.