ConversionRuler Coding Best Practices

When writing JavaScript code to instrument a site using there are a few best practices and issues which are a common issue to deal with:

Safe ConversionRuler Code Execution

This pattern for any code on your site:

<script>
(function (w) {
    w._crq = w._crq || [];
    w._crq.push(function (cr) {
        // ConversionRuler instrumentation goes here
    });
}(window));
</script>

Or:

<script>
window._crq = window._crq || [];
window._crq.push(function (cr) {
    // ConversionRuler instrumentation goes here
});
</script>

Should be used; largely as it has some quite beneficial side effects:

1. This code is run immediately once ConversionRuler loads (use __CR.ready and other calls to defer instrumentation as needed)
2. This code will not run if ConversionRuler is not loaded (due to an error on the page or any other issue) as the code is run by ConversionRuler's _crq functionality.

Where forms are actually located

With modern web marketing services, many sites use 3rd-party form collection and analytics tools such as HubSpot, Salesforce, ActOn, Gravity Forms and related tools.

3rd party tools such as these often have the following types of issues:

• Content is loaded remotely, often after the main page loads, so form elements are unavailable immediately to instrument - these tools often place iframe elements on a page which creates security issues
• Content is often loaded on a 3rd-party domain name which is inaccessible from the primary domain name due to security on the browser

The timing issues should be handled by one of two methods:

• Adding __CR.ready calls wrapped around instrumentation which requires the entire DOM loaded prior to instrumentation
• Modifying code to use a watcher pattern to wait for an element to appear

When things are loaded

Most instrumentation issues have largely to do with loading order of items on a page