Use the plugin. It is one setting and it survives a theme change, which the alternatives do not.

The plugin

  1. Open skomi-plugin-wordpress and, under Releases, download the skomi-wordpress.zip attached to the latest one.
  2. In WordPress, go to Plugins → Add New Plugin → Upload Plugin, choose the file, install and activate it.
  3. Go to Settings → Skomi Analytics.
  4. Paste your site ID and save.

⚠ Take the zip from the release, not the green "Code → Download ZIP" button. That one wraps everything in a folder named after the repository and the branch, and WordPress installs a plugin under whatever folder the zip contains. The plugin would land under the wrong name, and the WooCommerce add-on below, which asks for skomi-wordpress by name, would stop finding it.

The site ID is on your site's page in Skomi. It is a UUID, and it is not a secret: it appears in the page source of every page it measures.

Two settings matter and the rest can stay as they are:

  • Enabled, which is on. Turning it off stops collection and keeps your site ID, so you do not have to go and find it again afterwards.
  • Site ID. An id that is not a UUID is refused with a message rather than saved, because a saved bad id prints a broken script tag onto every page.

One default worth knowing: visits by people signed in to WordPress are not measured. On a small site your own reloads outnumber real traffic, and nothing in a dashboard says so. There is a checkbox if you want them.

If you sell through WooCommerce, add Skomi for WooCommerce as well, installed the same way. It reports each order's total, currency and order number, and it is the order number that stops a refreshed thank-you page counting a second sale.

Both are uploaded rather than found in the plugin directory: they are not on wordpress.org. The source of both is public, and the whole of it is worth reading before you install anything onto a site that takes money.

Pasting the tag by hand

You do not need this if you used the plugin. It is here because some sites cannot add one, and because a tag pasted into a theme is the most common way analytics quietly stops on WordPress. A theme change takes it with it, with no error and nothing to notice.

Get the snippet from your dashboard first. It looks like this, with your own site ID in the path:

<script src="https://t.skomi.com/s/your-site-id.js" defer></script>

The option to reach for if you would rather not touch a theme. Plugins such as WPCode or Head & Footer Code add a settings page with a box for the header and a box for the footer. Paste the tag into the footer box and save.

This survives every theme change and every theme update, which is the whole argument for it.

A child theme

If you already run a child theme, add this to its functions.php:

add_action( 'wp_footer', function () {
    ?>
    <script src="https://t.skomi.com/s/your-site-id.js" defer></script>
    <?php
}, 100 );

wp_footer fires just before the closing </body> tag, and the priority of 100 puts the tag after the scripts WordPress enqueues at the default priority of 20.

⚠ A child theme, not the theme itself. Editing a parent theme's footer.php works until that theme updates, and then the tag is gone with no error and no sign that anything changed. You simply stop collecting.

Your theme's own field

Many commercial themes have a "custom code", "tracking code" or "scripts" setting. If yours does, that is the same idea as a header and footer plugin with one fewer thing installed. Use the footer or body field rather than the head one.

⚠ It is also the option that disappears with the theme, so it is the weakest of the three unless you are certain the theme is permanent.

What your caching plugin will do

This applies however the tag got onto the page, plugin or not.

Purge the cache after adding the tag. A cached page was generated before the tag existed and does not contain it, so nothing arrives and nothing is wrong.

Exclude the Skomi script from "combine JavaScript" and from any option that copies third-party scripts to your own server. Skomi builds a bundle per site from the products you have switched on, and the browser is meant to fetch the current one. A copy pinned inside your optimisation plugin's bundle is frozen at the day it was copied: switching a product on later would change nothing, and there would be nothing to see that explained why.

Optimisation plugins that only defer or delay the script are fine. The tag already carries defer.

More than one site

WordPress multisite, or several installations, means several sites in Skomi: each domain is registered separately and gets its own ID, and each subsite needs its own tag. Subdomains of a registered domain are accepted by the site they belong to.

Check it is working

Load a page of your site and then look at your dashboard. If nothing arrives, work through what to check when the snippet is not working. On WordPress the answer is almost always a cache that has not been purged, or an optimisation plugin that has rewritten the tag.