A visitor can learn a lot about your product without opening another page. They might choose a plan in a pricing panel, play a short video, copy a setup command, or click a button that opens a form. In a single page app, they might do all of that while the URL stays put. If you look only at pageviews, much of that work is invisible.
This is a familiar problem for a small team. You have enough traffic to ask useful questions, but not enough time to turn every interface detail into a reporting project. You want to know whether people reach the moments you designed for them, where they hesitate, and which steps deserve attention. Hitsteps Custom Actions give those moments a name. You send an Action when something meaningful happens, then inspect it alongside the wider picture of visits and pageviews. The important actions can become Goals, so the team has a clear definition of conversion.
The trick is restraint. A useful Action plan starts with a handful of decisions people make, not a record of every movement on the screen.
What a pageview cannot tell you
A pageview tells you that a page was viewed. It cannot tell you which option someone selected inside it. That gap is especially obvious when a page is interactive. A pricing page might show three plans without loading a new page when someone picks one. A signup form might open in a panel. A video might play in place. A copy button might give someone exactly what they came for, with no next page to show it.
Think about a site owner who sees visits to a setup guide but few visits to the next guide page. Did readers leave because the first guide was unclear, or did they copy the command and go to their own terminal? Pageview data alone cannot settle that question. A carefully named copy Action gives the team one more piece of evidence. It still does not reveal what the reader did after copying, but it keeps a useful step from disappearing entirely.
Custom Actions are sent with hitsteps.trackAction('key','value'). hitsteps.action is an alias. An Action does not create a pageview, so tracking a click will not inflate your pageview count. That matters when you want pageviews to keep their plain meaning while you add detail about what happened within a page.
Start with the decisions you would act on
Before adding code, ask what you would do differently if an Action were common, rare, or absent. If the answer is unclear, you probably do not need to track it yet. A short list is easier to implement, check, and discuss than a catalogue of every tap and hover.
For a typical small site or single page app, the first list might look like this:
- A primary button click that shows interest in a product or service.
- A signup form submit attempt, and a separate confirmed success if the application can observe it.
- A plan pick that indicates which option someone is considering.
- A video play on a page where the video explains the offer.
- A copy-to-clipboard click for a code sample, link, or setup instruction.
- An outbound click that sends someone to a relevant external destination.
These are examples, not a checklist to install everywhere. Choose the actions that answer a real question for your site. A documentation site may care more about copied commands than pricing choices. A service business may care most about contact form attempts and confirmed submissions. A store with a custom plan selector may need to know which choices lead people toward checkout. The useful list follows the work visitors came to do.
Write the question next to each proposed Action. For a video play, ask whether visitors use the explanation beside the signup form. For a plan pick, ask whether people choose an option before leaving the page. This small exercise stops the Action list from becoming a collection of events no one knows how to interpret.
Be careful about what an Action represents. A button click is evidence of a click. A plan pick is evidence of a choice in the interface. Neither proves that a signup or purchase happened. Choose separate names for separate stages so the team can read the result without mentally adding success that the data never recorded.
Give keys and values a consistent job
Good names make Actions readable months after the code was written. One simple convention is to use the key for the object or step, and the value for the action or outcome. Use lowercase words joined with underscores. Keep the words close to what someone actually did.
hero_ctawithclickedmeans the main button was clicked.signup_formwithsubmit_attemptmeans the form was submitted by the browser, before you know whether it succeeded.signup_formwithsubmit_successmeans your application confirmed a successful submission.pricing_planwithstarter_selectedmeans the visitor chose the Starter option in the interface.intro_videowithplaymeans playback started.install_commandwithcopy_clickedmeans someone clicked the copy control.partner_linkwithclickedmeans someone clicked an outbound link you chose to track.
The exact words are less important than agreement about their meaning. Decide whether signup_form includes every form or only the first signup form. Decide whether pricing_plan records the displayed option, the option clicked, or the option confirmed in a later step. Then keep that decision stable. If the meaning changes, use a new name rather than silently reusing an old one.
Avoid a single key such as button paired with values that try to describe your entire site. It is hard to read and easy to grow without a plan. Also avoid names that promise more than the event can prove. purchase_complete is a poor name for a pricing button click. A plain pricing_plan and starter_selected pair leaves room for a later, genuinely confirmed outcome.
Keep a small shared list of names and definitions near the code or in the team’s working notes. Include the screen, the event that sends the Action, and the question it answers. That note helps when someone changes a button, adds a new plan, or wonders why two similar values exist.
Add Actions where the event really happens
Custom Actions need the normal Hitsteps install on the site. That can be the JavaScript snippet before </body>, the WordPress plugin, Shopify app, GTM template, Wix app, or Joomla extension. Install it only once. After that, add Action calls at the interaction points you chose.
Here is a plain JavaScript example for a primary button. The listener checks that the button exists, and the Action call checks that Hitsteps is available. Adjust the element ID and names to match your site.
var demoButton = document.getElementById("request-demo-button");
if (demoButton) {
demoButton.addEventListener("click", function () {
if (window.hitsteps) {
hitsteps.trackAction("demo_cta", "clicked");
}
});
}This records a click on that button. It does not say whether the visitor completed the form that may follow. If the button opens a panel, keep the name about the click or panel opening. Give a later submission its own Action.
For a form, the browser’s submit event is a useful place to record an attempt. The example below leaves the form’s normal behavior alone. It records the attempt when the event fires, not a confirmed success.
var signupForm = document.getElementById("signup-form");
if (signupForm) {
signupForm.addEventListener("submit", function () {
if (window.hitsteps) {
hitsteps.trackAction("signup_form", "submit_attempt");
}
});
}If your application has a clear success point after the form is accepted, send signup_form with submit_success there as a separate Action. Put it in the success path you already trust, rather than treating every submit attempt as a conversion. A failed validation, a server error, or a visitor who never finishes the process should not be described as a successful signup.
The same rule applies elsewhere. Track a plan pick when the selection actually changes. Track a video play when playback begins, if that is the behavior you care about. Track a copy action at the point that matches your definition, whether that is the click on the copy button or a confirmed copy operation your code can observe. For an outbound link in a single page app, track the click in its handler. Keep the name about leaving for that destination, since the click alone cannot tell you what happened on the other site.
An optional third argument can pass Custom Dimensions for an Action. Use that only when a stable, nonpersonal distinction would make the Action more useful. The first two arguments should still tell a reader what happened. If an Action needs a long explanation or a pile of extra context before it means anything, the naming or the tracking choice probably needs another pass.
Keep values short and free of personal data
Action names should describe behavior, not identify a person. Do not put email addresses, names, phone numbers, or other personal data in keys or values. A form’s entered text is not an Action value. Neither is a copied access token or the full contents of a message. Use a category such as contact_form and a state such as submit_attempt instead.
There are also format limits worth respecting while you choose names. A key can be up to 64 bytes and a value up to 255 bytes of UTF-8. Neither can contain control characters. Because the limits are in bytes, a name with non-ASCII characters can reach the limit sooner than its character count suggests. Short, plain names are easier for people to read and easier to keep valid.
An invalid Action is dropped. It never falls through to a pageview. If an expected Action is missing, check the values and the place where the call runs rather than assuming it appeared in another metric. This is another reason to use a small, reviewed vocabulary instead of building values from arbitrary user input.
Test the journey as a visitor would
Once the code is in place, open a private window and make the journey yourself. Start with a fresh visit to the page. Click the button, select a plan, play the video, or submit the test form in the order a visitor might. Then open the Actions explorer for that site in the Hitsteps dashboard and look for the names you expected. The usual login and site privacy settings apply to that dashboard area.
Check the names as carefully as the presence of the Action. Did the button click create demo_cta with clicked, or did a different element send the same pair? Does the form show submit_attempt before a success is known? If you have a confirmed success event, does it appear only after the application reaches that point? Read the Actions as someone who did not write the code would read them.
Repeat an interaction deliberately and see whether the additional Action makes sense. If one click produces two copies when you expected one, inspect where listeners are attached and whether the tracking install or your own event code was added more than once. Check that interactions within a single page app are covered even when no new pageview occurs. Also check that adding Actions has not changed the meaning of your pageview count, since an Action itself does not create a pageview.
If an Action does not appear, work from the simplest possibilities: confirm that the normal Hitsteps install is present once, that the event handler runs, that window.hitsteps is available when it runs, and that the key and value fit the format rules. Keep the test focused on a known interaction. A broad, complicated journey makes it harder to tell which step failed.
Read Actions as evidence, not an explanation
Once Actions are arriving, they can make a page more legible. You may see that people pick plans but rarely reach a confirmed signup. You may see that a guide gets copy clicks even when readers do not open another guide page. Those observations can direct a useful review of the page. They do not, by themselves, tell you why visitors acted that way.
Counts are not causes. A low video play count might mean the video is hard to find, or it might mean the surrounding text already answers the question. A high button click count might reflect genuine interest, repeated attempts, or a button that did not behave as expected. Ask what else you would need to know before changing the page. Often the next step is simply to try the journey yourself and look at the content beside the control.
Compare Action counts with visits, rather than reading them in isolation. Visits give the activity a useful scale. Remember that one visit can contain repeated clicks or selections, so an Action count is not automatically a count of different people. Pageviews, visits, new and returning visitors, and bounces remain separate metrics with their own meanings. An Action adds detail about a moment inside that picture. It does not replace the picture.
Make comparisons between similar periods and similar traffic where you can. A change in the Action count may reflect a change in visits, a different mix of visitors, a layout change, or a tracking change. If you have just renamed an Action or moved its code, note that before treating a jump or drop as visitor behavior. Honest interpretation often starts with checking the measurement itself.
Turn meaningful outcomes into Goals
Some Actions are useful context. Others are the outcome the team is working toward. A Goal is a conversion, with optional revenue, and Goals are available from the Growth plan. Decide which actions count as conversions and set them up as Goals. A confirmed signup may qualify. A click that merely opens the signup form is more likely a step toward it. Your definition should match the outcome your team would actually celebrate or investigate.
It helps to draw a simple line between interest, progress, and completion. A video play may show interest. A plan pick may show progress. A confirmed form success may be completion. These are ways to reason about your own site, not a claim that every visitor follows the same path. Someone may skip the video and still sign up. Someone may pick several plans before making a decision.
Segments are audiences for analysis, alerts, and Funnel stages. If your question is about a particular audience, use a Segment to keep that context clear. Funnels are ordered Segment stages and are available on the Pro plan. They are useful when you want to consider a sequence, such as reaching pricing, choosing a plan, and arriving at a later outcome. Keep the stages tied to observable behavior. Do not make a plan selection stand in for a completed signup just because it sits near the end of the journey.
A practical first pass
Suppose your site has a pricing section inside a single page app. The visitor can open a comparison panel, select a plan, then submit a signup form without a new pageview. Start by naming the outcomes you can genuinely observe. You might record the comparison button click as pricing_compare with clicked, the plan choice as pricing_plan with a value such as starter_selected, and the form event as signup_form with submit_attempt. If your application confirms that signup succeeded, send signup_form with submit_success at that point.
Now read that sequence with care. A visitor could compare plans and stop. Another could choose a plan twice. A third could submit the form and encounter an error. The Actions give you a record of those distinct steps. They do not require you to treat every step as equal or to guess why someone stopped. If confirmed signup is your real outcome, that is the Action to consider as a Goal. The earlier Actions help you understand the route to it.
A short checklist before you ship
- Pick a few visitor actions that answer questions your team would act on.
- Use consistent keys for steps or objects and values for actions or outcomes.
- Separate attempts, selections, and confirmed successes.
- Install the normal Hitsteps tracker once, then add Action calls at the right events.
- Keep personal data out of keys, values, and optional Custom Dimensions.
- Test in a private window and inspect the Actions explorer for the site.
- Compare Actions with visits, and decide which confirmed outcomes should become Goals.
Start with the action you most wish your pageview report could explain. Give it an honest name, test it, and see what it adds to the story in your Hitsteps dashboard.
