AJAX GET condition de course?

Question

Je tente de suivre les événements lorsque des liens sont cliqués sur mon site dans une méthode similaire à celle ci-dessous.

<a href="/example" class="track">Example</a> 

<script type="text/javascript"> 
    jQuery(function($) { 
     // track clicks on all anchor tags that require it 
     $('a.track').live('click', function(e) { 
      // send an AJAX request to our event tracking URL for the server to track it 
      $.get('/events/track', { 
        url: $(this).attr('href'), 
        text: $(this).text() 
      }); 
     }); 
    }); 
</script> 

Le problème que je vais avoir est qu'une nouvelle charge page interrompt la requête AJAX, et donc parfois ces événements ne sont pas suivis. Je sais que Google Analytics a une fonction _trackPageview qui peut être attachée aux événements onclick, et cela ne semble pas être un problème pour cela. Je me demande ce qui est différent dans leur appel vs le mien que je vois cette condition de concurrence, et GA ne l'est pas. .: par exemple

<a href="/example" onclick="javascript:pageTracker._trackPageview('/click/example');">Example</a> 

Notez que je ne suis pas inquiet du résultat de la requête AJAX ... Je veux simplement faire un ping le serveur avec le fait qu'un événement est arrivé.

(En outre, je pense que j'obtiendrai au moins une réponse qui dit de simplement suivre le chargement de la nouvelle page du côté serveur, pas du côté client .Ce n'est pas une réponse acceptable pour cette question. à la recherche de quelque chose comme la façon dont la fonction de Google Analytics trackPageview travaille sur l'événement click des balises d'ancrage indépendamment d'une nouvelle page en cours de chargement.)

Answer 1

Exécution méthode de Google trackPageview via un proxy comme Charles montre que les appels à trackPageview() demande un pixel de Les serveurs de Google avec divers paramètres définis, ce qui est la façon dont la plupart des paquets d'analyse finissent par mettre en œuvre de telles fonctionnalités (Omniture fait la même chose). Fondamentalement, pour contourner les demandes anynchrones qui ne se terminent pas, le client demande une image et croque les paramètres passés dans ces requêtes côté serveur. De votre côté, vous devez implémenter la même chose: écrire une méthode utilitaire qui demande une image à votre serveur, en transmettant les informations qui vous intéressent via les paramètres d'URL (quelque chose comme /track.gif? page = foo.html & link = Cliquez sur% 20Me & bar = baz); le serveur consignerait alors ces paramètres dans la base de données et renverrait le gif. Après cela, il s'agit simplement de découper et de découper en tranches les données que vous avez collectées pour générer des rapports.

Answer 2

Matt,

Si vous voulez juste vous assurer que la demande de pixel de suivi est fait et vous ne dépendent pas de réponse alors faire juste document.write pour l'image de pixel de suivi fera le travail.

Et vous pouvez faire le document.write dans votre gestionnaire onclick.

AFA condition de course entre href et onclick handler de l'élément d'ancrage est concerné l'ordre est bien défini.

le script du gestionnaire d'événements est exécuté en premier l'action par défaut a lieu après (dans ce cas, le gestionnaire par défaut est href) (Source: Href and onclick issue in anchor link)

Mais oui, si vous dépendez de la réponse du suivi demande au serveur alors vous devrez le rendre synchrone.

L'option suggérée serait d'appeler une fonction javascript pour envelopper les gestionnaires onclick déjà définis, puis dans l'ordre faire les appels. Assurez-vous que votre demande de suivi n'est pas asynchrone.

Bien qu'il soit suggéré de ne pas dépendre de la réponse de la demande de pixel de suivi.