7 Replies Latest reply on Mar 1, 2015 4:05 PM by 5a271c99ac96150fc8e3caa5b88fb4e44ad2d366

    munchkin api confirmation/or error management

      Is it true that there is no way to error check munckin api pushes? e.g. I want to create/update a lead on successful form submission. If all is well, then registration is fine; however, what if there is an unforseen error on the munchkin api side. How will I know that lead Z never got input into marketo in order to resolve?
        • Re: munchkin api confirmation/or error management
          Sanford Whiteman
          Tell me more about the Munchkin API methods you're using -- are you calling associateLead()?

          Such methods work by GETing a tracking image outside the DOM and they don't fire an error/success callback. The reason I mention outside the DOM is that, if they actually inserted the tracking images, you could wrap everything in document.body.addEventListener('error',...) and this would fire on a failure to load the image (i.e. a 4xx or 5xx response).  

          By staying out of the DOM these methods are more efficient. But I am not aware of a way to reliably trap on errors without customizing the Munchkin code (which you could also, in theory, do).  
          • Re: munchkin api confirmation/or error management
            A 1 page submit form. The form submits back to a controller. On success we 
            1. munchkin track viewpage
            2. associateLead
            On success we push to Marketo; however, how am I assured that Marketo received all my leads? I should be able to somehow say - {if marketo success: continue; else: log} - either on the Marketo Side* or on my application side.

            With this i can periodically check the logs and see: Jon Doe was not entered. With that I can then retry Jon Doe. Since the email is unique, possibly email should be a key instead of the full name. With this, we can continue to automate the system:

            Get all errors.
            For each errors:
              Resubmit lead by email address
            • Re: munchkin api confirmation/or error management
              Sanford Whiteman
              OK, let's start with two complementary technical points:
              1. Getting a positive response back from a remote HTTP call doesn't necessarily mean data was durably committed to a database, because the system may return 200 OK when it merely has put the db request in a work queue.
              2. Gettting no response doesn't mean that data was not committed, because a network problem during the response phase does not mean the request was not processed or queued.
              Together, what these mean is that only a literal negative response (400 Bad Request) can be taken at face value during the HTTP transaction itself.  

              Expanding on [1], with a high-volume analytics service like Munchkin you shouldn't expect data to be synchronously committed to the db before the 200 OK is sent.  You should expect it to be more "fire and forget" where getting the request all the way to the analytics server as fast as possible is the goal.  The data may be in your instance by the time the response is coming back to you, but if it takes another half-second or couple of seconds, that's still "success" in the grand scheme.

              Expanding on [2], if Munchkin were to run a callback on success, you couldn't actually take the lack of a callback as evidence that the data did not get into your instance.  For example, anytime the user navigated to a new page before the response was received, you the callback wouldn't have a chance to fire before the request was aborted.  But that wouldn't mean the data didn't get into their Activity Log in Marketo.  

              What I'm trying to say is that any kind of audit trail would be pretty fuzzy.  I don't mean that Munchkin couldn't give us a better idea of whether the tracking image request was known to fail or not -- it would be great if they did.  I just mean that wouldn't be the whole picture.

              Using the REST or SOAP API you can download the most recent activity logs and compare them with your expectations.  For that to be useful, you must also maintain another set of ostensibly lossless/authoritative analytics. What we do (I don't necessarily favor it, but there it is) is log the same data to Google Analytics at (approximately) the same time as Munchkin.  But we are not looking for fine-pointed analysis, rather for gross discrepancies.  If Munchkin looks grossly below GA then we could in theory replay by downloading from GA and using the Marketo API. Luckily we have not had to do that.
              • Re: munchkin api confirmation/or error management
                i notice data is still not tracking as yet. I am using async jquery. 

                <script type="text/javascript">
                  url: '//munchkin.marketo.net/munchkin.js',
                  dataType: 'script',
                  cache: true,
                  success: function() {
                    Munchkin.init('xxx-xxx-xxx', {"cookieAnon":false});

                How would the code look for Visit Web Page and Associate Lead? This isnt mentioned in the docs
                • Re: munchkin api confirmation/or error management
                  I guess the code just goes in the success function? I guess I wont be able to use a tag manager here. Thats the dilema 
                  • Re: munchkin api confirmation/or error management
                    Sanford Whiteman
                    I'm not sure what satisfaction you expect to get from the code above.  You'll get success when Munchkin.js is loaded, but you still won't get a callback when the tracking is complete.

                    It is nice to know if Munchkin.js doesn't load, but that's not the tracking code. Munchin.init calls() View Web Page automatically.

                    There are examples of associateLead and visitWebPage in the docs.

                    Also, why exactly are you using cookieAnon:false?
                    • Re: munchkin api confirmation/or error management
                      Sorry for the confusion. This last comment was meant for another thread.