Is it possible to set cookies in a mobile app so Marketo can track behavior?

[Anonymous]

We are working on a native mobile app (for iOS and Android), and while app users will be anonymous to us, we will be implementing some Marketo forms within the app.  Is it possible for those forms to set a cookie in the app in the same way they do on a web page?  We'd like the ability to track and score behavior in the app as we do on our website.

[Josh_Hill13]

Please see developer.marketo.com for details on using the munchkin API.

[Anonymous]

A native app can use cookies, but you will create a duplicate anonymous user for every app user unless they login with the same email address. 

[Anonymous]

Adam, so I assume this means scoring will be aggregated to this one anonymous user.  Is that correct?  If a user becomes a lead because they fill out a form, does their scoring start at 0, or is the anonymous user score merged with it?

[Anonymous]

You would need to test this to be definitive, but I assume it's additive where it would combine the two scores when the two leads become merged. But I'm not 100% certain on that.

[SanfordWhiteman]

There won't be one anonymous user in total, there will be one anonymous user per unique cookie -- i.e. per device or even per device user, depending on how you author your app.  

[Edward_Unthank_]

Re: scoring fields.

Native scoring fields (e.g., Lead Score) will be additive, but custom SFDC fields for scoring (even after being changed to "score" type in Marketo) are treated like integers and will be merged (and overwritten) like normal integer fields. So if you have hefty custom behavior scoring happening at the anonymous level, it will in most cases be overwritten when the lead becomes known. 

I haven't tested to see if this applies to Marketo-created custom fields which are chosen as "score" to begin with—generally, if a field needs to be visible to both Marketo and SFDC, I advocate creating them directly in SFDC so you don't have to worry about the more-complex-than-you'd-think task of mapping Marketo fields to SFDC fields and vice-versa.
 

Best,

Edward Unthank | Founder, Etumos

[Anonymous]

Hi Allison
 
Why do you want to use Froms2.0 and cookies in Native app.
Normally, I consider these.
- The user entrys own profile(include email adress ) at Native UI form. After this, App make a call "Create Leads" via REST API.
http://developers.marketo.com/documentation/rest/createupdate-leads/
- When the user uses this app, make a call "Request campaign". Marketo append an activity record. 
http://developers.marketo.com/documentation/rest/request-campaign/

Note that:
API limit is 10000 calls per day. If calls are over it, we make a relay server, and make a call in batch style.
We will replace "Request Campaign" to "Write custom activity" or "Add custom activity".
Their current status are beta.
http://developers.marketo.com/documentation/rest/add-custom-activities/
http://developers.marketo.com/documentation/rest/write-custom-activity/

[Sarah_Greig2]

What is the main difference and benefits to using Forms 2.0 vs API call within a Native App?

[SanfordWhiteman]

What is the main difference and benefits to using Forms 2.0 vs API call within a Native App?

The difference between these two methods of creating/updating lead fields is one of capacity.  The REST/SOAP API only allows 10,000 calls per day across your entire instance. It is not suitable for singleton end-user events, that is, using one API call for every one user action. The moment a hacker tries to break your service, you're toast.  In contrast, the Forms 2.0 endpoint can accept 30 posts per hour from every IP address.  Provided posts are 2 seconds apart, that's 43,200 posts per day per IP -- an astronomical difference.  Between these two methods only the Forms endpoint should be used by a professional organization.

For creating lead activities, the choice is similarly clear.  The REST/SOAP API is not suitable for logging singleton lead activities, because it is comically easy for as junior hacker to deny service.  The Munchkin endpoint can be used to do this, as it is designed for real-world scale.

It should also be mentioned that REST/SOAP APIs can't be used directly from an app.  For security, those APIs must be used from your server, so the app connects to you and then you connect to the endpoint. It's more infrastructure to maintain.  Though frankly this is a minor concern compared to the above.