DISCLAIMER: Even after reading this you will have to do some work to adapt this to your environment. Generally, we don’t offer customized instructions about how to integrate Fullstory into your specific site, simply because there are too many variations of what you could be using for your hosting, for your server software, for your site design, for user information... you get the idea!
We've gotten a few questions about integrating Fullstory with a WordPress site and we think that sometimes a very specific how-to can go a long way toward explaining things. This doc will refer to WordPress and its WooCommerce plugin.(Note: That’s not a recommendation on our part. We don’t use either of those tools ourselves and we think you should use whatever tools you choose! This is an example from an actual support case, so we know at least one of our users does use it.)
Inserting the Data Capture Snippet
To get Fullstory up and running you need to follow these instructions. In WordPress, there are a few ways to actually make this happen.
Manually Editing header.php
If you choose this manual method, it is possible that when you update WordPress to a new version, that new version will erase your changes and stop your Fullstory data capture. You would then have to repeat these steps.
- Open the WordPress installation directory
- Use any text editor (Notepad, Text Edit, vim, etc.) to open header.php
- Search for “<head>” to find the HTML <head> and </head> tags
- Paste the data capture snippet into the file as shown below, in pink
- Save the file
Now users to your site should have their sessions captured by Fullstory!
Editing header.php with a WordPress Plugin
In the earlier method, you may have noticed that header.php has a call to WordPress’s wp_head() function. Not all of their themes use that and if your theme doesn't, a more sustainable way to inject the data capture snippet would be to use a plugin. (Example: Header and Footer plugin. Not a recommendation, just something we’ve seen used).
Once you've installed a plugin that can manipulate headers, navigate to the Settings section for that plugin (you'll likely need to be an Admin). The plugin settings should offer a place to paste the data capture snippet into the <head> section of your pages.
Again, we can't promise this will always be the case, but in this example it was nice and easy:
Adding FS.identify
Once you've installed the Fullstory data capture snippet, you will likely want to associate your users with their actual identity.
We did this in the same place as the previous step by modifying the script that we pasted in the <head>. The screenshot below shows a few lines we added at the end of the data capture snippet, just before the closing </script> tag.
Take note of the <?php and ?> markers. These markers are used by the WordPress server to run a bit of PHP in WordPress as it generates the page. They use WordPress’s wp_current_user() function to get the user’s email, print it onto the page, and then into the script that the browser will use.
The rest of the script is run as JavaScript in the browser. It defines a wpEmail variable with the server-supplied email address and calls FS.identify to use that variable as a unique ID (uid) for this user. It also uses this uid as the display name and email address of the user. And just like that, Fullstory learns which user captured each session!
You may ask why this isn’t part of the data capture snippet itself. The reason is that each environment give information in a different way and we need WordPress to tell Fullstory the user information. Since we can’t know your exact environment, we can’t include it in the snippet for you.
Adding Commerce Information (User Variables)
We can use other PHP functions to get more information from the WordPress server, and pipe in that additional information to provide useful context for users and their sessions. Exactly what information is available---and how you get at it---isn’t up to Fullstory, but is instead controlled by the other plugins you may be running with WordPress.
As an example, if you happened to be using Woo Commerce (again, not a recommendation...) you would have the available functions wc_get_customer_order_count and wc_get_customer_total_spent. The below is an example of capturing these WordPress + Woo Commerce specific custom variables.
The example also includes the use of WordPress’s is_user_logged_in call, which will avoid identifying unknown users. This is important to avoid falsely identifying anonymous users and accidentally grouping them together into one anonymous user with an email address of “”.
You would replace the earlier edition (from further up in this article) of the data capture snippet with the following:
})(window,document,window['_fs_namespace'],'script','user');
<?php if (is_user_logged_in()) { ?>
var wpEmail = "<?php $current_user = wp_get_current_user();
echo $current_user->user_email; ?>";
var count = <?php echo wc_get_customer_order_count(get_current_user_id()); ?>;
var spend = "<?php echo wc_get_customer_total_spent(get_current_user_id()); ?>";
FS.identify(wpEmail, { "displayName": wpEmail,
"email": wpEmail,
"orders_int": count,
"totalSpent_real": spend });
<?php } ?>
</script>
Notice that the total spent is a string (as returned by Woo Commerce’s wc_get_customer_total_spent), which is why there are quotes around that when the variable spend is assigned, but the order count is an integer and doesn’t need to be quoted.
Using the code snippet above, you can see that the first call uses PHP to check whether the user is logged in. Here is how that will look in Fullstory:
- If they aren't logged in, Fullstory will track this user uniquely by assigning a uid, but can’t assign any identifying information such as name or e-mail yet. The uid will be used to continue associating sessions to the same user, no matter if they log in later or never login.
- If the user is logged in, Fullstory will get the email from WordPress as well as how many orders the customer has placed and how much money the customer has spent, from Woo Commerce (again, based on the above snippet using those unique WP functions).
The FS.identify call captures the user information so that you can run specific searches, such as "Users who Never placed an order and logged a Dead Click". Returned results for this search may mean you've got a broken checkout button <gasp>.