Configuring Events and Signal Templates

Events are the signals your users generate when they interact with your product: views, clicks, purchases, shares, and any other action you decide is meaningful. NeuronSearchLab uses these signals to learn each user’s preferences and improve ranking quality over time. This guide explains how to define event types, set their relative importance, and organise them into templates for training. The key idea is:

the Events page is where you define the training recipe
a template is that recipe
starting training from a template creates a new trained version
review, approval, naming, and promotion happen later on the Models page

Event types

An event type has an NSL-generated integer ID, a human-readable name, and a weight. Send the integer ID in API and SDK calls; names such as click are labels, not ingestion identifiers.

Add an event type

Open Events

Open Console > Events.

Name the event

Enter a name in the Event name field, for example click, purchase, or video_complete.

Set a signal weight

Set a weight between 1 and 100. Higher weight means the training process treats that signal as more informative.

Add the event

Click Add event.

A common starting point:

Name	Weight
impression	1
click	10
add_to_cart	30
purchase	100

You can adjust weights at any time. Changes take effect on the next training run.

Send events from your application

Copy the integer ID from Event configuration when tracking actions via the SDK:

await sdk.trackEvent({
  eventId: 42,
  userId: "user-123",
  itemId: 3187,
  contextId: 101,
  metadata: { placement: "homepage" },
});

Or via the REST API:

curl -X POST https://api.neuronsearchlab.com/v1/events \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -d '[{
    "event_id": 42,
    "user_id": "user-123",
    "item_id": 3187,
    "context_id": 101,
    "occurred_at": 1777478400
  }]'

Searches are events

When a user searches, their intent is unusually clear, so a search is recorded as an event like any other: an event with a query and no item, on the event type your search signal is bound to. It carries that event type’s weight, so a search weighted 25 counts a quarter of a purchase weighted 100, exactly as a click weighted 25 would. Send one in any of three ways:

Call	Who ran the search	What comes back
`POST /v1/search` with `query`	NSL	Ranked search results
`POST /v1/search` with `query` and `result_item_ids`	Your own search engine	Recommendations that complement your results
`POST /v1/events` with `query` and no `item_id`	Your own search engine	The recorded event

await sdk.trackSearch({
  userId: "user-123",
  query: "waterproof trail shoes",
  resultItemIds: [3187, 3190, 3201], // what your engine showed, optional
});

The items a search showed are kept as impressions. They are never counted as items the user chose, so they do not reach training, “exclude viewed items”, or popularity. When the user then opens a result, send that as a normal click with the item and, optionally, the query it came from.

How searches steer recommendations

On each later recommendation request for that user, NSL weighs their searches from the last 14 days against their item events. Each signal counts its event weight and halves every 72 hours. The searches’ share of that total is how far the recommendations lean towards them:

the items closest to each search join the candidates, with slots split between searches by weight, so three different searches bring three kinds of item rather than one blurred average;
after ranking, the order is blended towards whichever search each item matches best, by that share, whatever model produced the rest;
your rules still apply afterwards, so a boost or pin you configured wins.

A request that already states a narrower intent (a search, an item_id seed, a basket or an auto section) is left alone. The response says what the searches contributed in search_intent, and each user’s drawer in Console > Users shows the same breakdown under Event History. To tune it, change the weight of your Search event. Set it to 0 to stop searches steering recommendations while still recording them, or turn off Search intent in a pipeline’s scoring stage to exclude one pipeline.

Integration signals

The embed, the Shopify app, the storefront adapters and the order and GA4 importers record behaviour for you. None of them send an event name. Each reports a signal - a fixed concept NSL defines, such as rec_click, add_to_cart or purchase - and your workspace binds every signal to one of your event IDs. That is what keeps events consistent across platforms. Shopify, Magento and your own server can all report purchases; they land on the one event ID bound to purchase, however each platform spells it, and nothing depends on case, spelling or a name someone chose.

Enabling an integration creates its events. Creating an embed key, or starting a Shopify or GA4 import, creates an event type for each signal it reports that is not bound yet, with a sensible default label and weight. Those event types count toward your plan’s event-type limit.
Every workspace starts with three bound events: View, Click and Purchase.
Nothing is matched by name. An event you created called “clicked” is not assumed to be the click signal.
Rebind to use an event you already have. Open Events → Integration signals and choose the event ID a signal should land on. The list shows which integrations report each signal.
A bound event cannot be deleted. Rebind its signal first, so no integration is left with nowhere to write.

Labels and weights stay yours to edit on every event, bound or not.

Signal templates

A template captures a specific combination of event types, weights, and training thresholds. Saving a template lets you reproduce a training run exactly or switch between different configurations without losing your settings.

Create a template

Configure event signals

On the Events page, configure your event types and set the thresholds described below.

Name the template

Enter a name in the Template name field.

Choose a status

Set the status to Draft (not yet used for training) or Published (ready to train from).

Save the template

Click Save template.

Training thresholds

Two thresholds control when a model is trained:

Per-signal threshold: the minimum number of events for each individual event type before that signal is included in training. Set this to avoid training on noise from rarely used signals.
Minimum total events: the minimum total number of events across all signals before training will proceed. This prevents a model from training on too little data to generalise.

Train from a template

Select a template

Select a saved template from the template list.

Configure training options

Configure the training options:

Epochs: how many passes through the training data (default 5, range 1-50).
Batch size: number of events processed together (64, 128, 256, or 512).
Learning rate: step size for gradient updates (default 0.001).

Start training

Click Start training. The console will create a new trained version from that template and show the run status as training progresses.

This step does not require you to already have a model record. New accounts can train immediately.

What happens after training

After a run finishes:

a new trained version appears on the Models page
the system gives it a default name based on the template and the run identifier
your team can add a human-friendly label and description
you can approve it
you can promote it to a serving target

If you retrain later, the platform creates another new version. It does not overwrite the earlier one.

Monitoring training runs

Open Console > Training Jobs to see the status of each run, its duration, and the metrics reported at completion. From this page you can:

View final training metrics and run manifests.
Stop an in-progress run if needed.

For approval, version labelling, and promotion, continue in Console > Models.

Analytics: measuring signal quality

After deploying a model, monitor how different event types are driving engagement in Console > Analytics. Track each event type as its own metric alongside recommendation serve counts to understand which signals correlate with downstream outcomes. If high-weight events are rarely occurring, consider lowering their weight or broadening what you treat as a conversion signal. If impressions are large but clicks are low, adjust your context filters and ranking rules before retraining.

Get Started

Recommendation Control

NSL Connect

Console Workflow

Developer How-To

Configuring Events and Signal Templates

Event types

Add an event type

Send events from your application

Searches are events

How searches steer recommendations

Integration signals

Signal templates

Create a template

Training thresholds

Train from a template

What happens after training

Monitoring training runs

Analytics: measuring signal quality

​Event types

​Add an event type

​Send events from your application

​Searches are events

​How searches steer recommendations

​Integration signals

​Signal templates

​Create a template

​Training thresholds

​Train from a template

​What happens after training

​Monitoring training runs

​Analytics: measuring signal quality

Event types

Add an event type

Send events from your application

Searches are events

How searches steer recommendations

Integration signals

Signal templates

Create a template

Training thresholds

Train from a template

What happens after training

Monitoring training runs

Analytics: measuring signal quality