Custom Properties

Custom properties let you segment your traffic by the things only you know about your pages and visitors: the author of an article, the plan a signup chose, the calculator a visitor used, whether they were logged in. You attach a key and a value to a pageview or an event, and Clickport turns it into a breakdown you can view, sort, and filter the whole dashboard by.

Two things set Clickport's implementation apart. Properties show up in your dashboard automatically the moment the first one arrives: there is no settings page where you have to register each property before it counts. And custom properties are included on every plan.

What a custom property is

A property is a key-value pair attached to a single pageview or event. The key names the thing you are measuring (author, plan, widget), the value is what it was for that specific view or action (Jane Doe, pro, solar-rechner). Values must be scalars: strings, numbers, or booleans. Objects and arrays are skipped.

Properties are not user profiles. Clickport stays cookie-free, so a property describes the pageview or event it rides on, never a persistent identity. That distinction is what keeps properties inside the privacy model that lets you run without a consent banner.

Real-world examples

Traffic by author and section

A publisher wants to know which writers and which sections actually pull readers. The article template emits two meta tags, and every pageview of every article carries them from then on:

<meta name="cp-prop:author" content="Jane Doe">
<meta name="cp-prop:section" content="Climate">

That is the entire setup. No JavaScript changes, nothing to configure in the dashboard. Open Goals → Properties, pick author, and you see visitors per writer for any date range. Click a writer to filter the whole dashboard: now Sources shows where that writer's readers come from, Pages shows which of their articles carry the load, and the KPI strip shows how engaged their audience is compared to the site as a whole.

Which plan converts

A SaaS tracks signups as a custom event. Adding the chosen plan as a property splits one event into an instant plan-mix report:

clickport.track('Signup', { plan: 'pro', trial: 'yes' });

The Properties tab now answers "how many signups picked which plan" for any period. Filter the dashboard by plan is pro and every panel reorients around your highest-value signups: which channel brings them, which landing pages they saw first, how long they stayed.

Which embedded tool gets used

A content site embeds calculators and checkers across hundreds of pages. Tagging each use with the tool's name shows which tools earn their maintenance cost:

clickport.track('Tool Used', { widget: 'solar-rechner' });

Sorting the widget breakdown by visitors gives a ranked list of your tools by real usage. Stack two filters (widget is solar-rechner and another widget is heizungsgesetz-check clause) and you see visits that used both tools in one session, which no pageview report can tell you.

Logged-in vs logged-out

When the same pages serve members and anonymous visitors, a single property separates the two audiences everywhere. The function form runs on every pageview, so it stays correct in single-page apps:

window.cpConfig = {
  customProperties: function () {
    return { logged_in: document.cookie.includes('session=') ? 'yes' : 'no' };
  }
};

Filter by logged_in is no and your funnel, top pages, and sources describe the acquisition side of your site. Flip it to yes and you are looking at member behavior. The value is computed on the visitor's device and only the string yes or no ever leaves the browser.

Three ways to send properties

Meta tags are the no-code path for pageview properties. Any CMS that can edit a template can emit them:

<meta name="cp-prop:author" content="Jane Doe">

The tracking snippet config attaches properties to pageviews from JavaScript, either as a static object or as a function evaluated per pageview. Define it before the tracker script loads:

// Static: same properties on every pageview
window.cpConfig = {
  customProperties: { section: 'blog' }
};

// Dynamic: computed per pageview (SPA navigations included)
window.cpConfig = {
  customProperties: function () {
    return { theme: document.documentElement.dataset.theme };
  }
};

Event properties ride on clickport.track() calls, documented in full on the Custom Events page:

clickport.track('Signup', { plan: 'pro' });

The three paths merge cleanly. Meta tags and config can coexist on the same page; if both define the same key, the config value wins. Meta tags are re-read on every SPA navigation, so per-page tags stay accurate in client-side routed apps.

Where properties appear

Open the Goals panel and switch to the Properties sub-tab. A selector lists every discovered property key ranked by volume; below it, the selected key's values with visitors, share, and event counts. All three columns sort.

A few details worth knowing:

• Clicking a value filters the whole dashboard by that property, the same as clicking a row in any other panel. Click it again to remove the filter.
• (none) collects views and events where the key was present but the value was empty. It is clickable and filterable like any other value.
• Hide removes a noisy key from the selector without touching the data. Hidden keys keep collecting and come back with full history when you unhide them from the Show hidden list. Hiding is per site and applies for your whole team.
• Percentages are each value's share of the selected key's visitor total.

Filtering by properties

Properties are a first-class filter dimension. Open the filter editor, expand Property in the Behavior section, and every discovered key is listed; pick one and choose values with the usual operators: is, is not, contains, does not contain. Typing in the value box searches all values server-side, not just the visible ones.

Filters compose the same way as everywhere else in Clickport:

• Several values in one filter are OR. widget is solar-rechner or steuer-check matches visits that used either.
• Several filters are AND. Add a second clause for the same key and you get visits that match both: visitors who used two specific tools in one session.
• Negation keeps property-less visits. author is not Jane Doe excludes visits that read a Jane Doe article; visits that read no articles at all stay in.

Property filters work with everything filters normally do: saved segments, share links, the exports, and the Stats API.

Limits, values, and privacy

• Up to 30 properties per pageview or event. Extra keys are dropped.
• Keys up to 300 characters, values up to 2,000 characters. Longer ones are truncated.
• Scalar values only. Numbers and booleans are stored as strings; objects, arrays, and functions are skipped.
• Avoid unbounded values. User IDs, timestamps, or full URLs as values create endless unique rows and tell you nothing. Use values from a bounded set: names, categories, plans, variants.

Query properties through the API

Everything the Properties tab shows is available programmatically. The Stats API accepts prop:<key> both as a filter dimension and as a breakdown dimension:

curl -X POST https://clickport.io/api/query \
  -H "x-api-key: ck_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "metrics": ["visitors"],
    "dimensions": ["prop:author"],
    "period": "30d"
  }'

See the API Reference for the full property querying documentation, including filter syntax and response shapes.