Network deduplication with last view/event logic (LEC) – Daisycon Advertiser FAQ

Last Event Counts, or LEC, helps advertisers use recent Daisycon view event data in their own deduplication setup. It is mainly used when post view attribution should be considered in deduplication between competing affiliate networks.

LEC is useful because a banner view does not set an advertiser-side cookie, click ID, or network flag by itself.

LEC should only be used when recent Daisycon post view data, must be considered in affiliate network deduplication. It is not a reporting API and should not be used for cross-channel attribution.

What is LEC?

LEC stands for Last Event Counts. It is a client-side Daisycon endpoint that can return recent Daisycon event data for a specific campaign and the visitor’s device or browser.

The endpoint can support advertiser-side deduplication logic. For example, an advertiser can trigger the endpoint on the visitor’s client and use the response to set or update an advertiser-side deduplication cookie or attribution marker.

Scope of LEC

LEC is intended to support deduplication between competing affiliate networks. It is not intended to deduplicate Daisycon traffic against other marketing channels or traffic sources.

Do not use LEC to suppress Daisycon post view attribution because another channel, such as SEA, paid social, display, email, or direct traffic, was also involved.

Post view attribution can show the value of publisher visibility within the affiliate channel. It should not be removed simply because a pre-paid or budget-based marketing channel was also part of the customer journey.

When should LEC be used?

LEC is mainly used when post view attribution should be included in advertiser-side deduplication.

The campaign uses post view attribution
The advertiser deduplicates between multiple competing affiliate networks
The advertiser’s current setup depends on click cookies, click IDs, or network flags
The advertiser wants to set its own deduplication cookie based on recent Daisycon event data

Why LEC is needed for post view attribution

Daisycon post view attribution is cookieless. When a user views a Daisycon banner, the view is registered through the banner material request. No advertiser-side cookie or network flag is set automatically.

The banner must be loaded from Daisycon servers for the view to be registered. If a publisher downloads the banner image and hosts it manually, the banner material request does not reach Daisycon and no view can be registered.

A strict click-based deduplication setup may therefore fail to recognize recent Daisycon activity when the user later visits the advertiser website directly. LEC makes the recent Daisycon event data available on the visitor’s client so it can be included in the advertiser’s deduplication logic.

The LEC endpoint

The endpoint has the following structure:

https://<tracking_domain>/js/lec/?ci=<program_id>

<tracking_domain> is the Daisycon tracking domain used for the campaign
<program_id> is the Daisycon campaign ID

The LEC endpoint returns JavaScript, not JSON. It should be loaded as a script on the visitor’s client. The response is made available through window.__dc_response.

Example response when a view is found

The example below uses fictional values.

var __dc_response = {

  "status": "G",
  "status_description": "Matching event found",
  "view": {
    "timestamp": 1789718400,
    "iso_date": "2026-09-18T10:00:00+02:00",
    "media_id": 67890
  }
}

Example response when no view is found

var __dc_response = {

"status": "V",
"status_description": "No matching event found"
}

Simplified explanation of LEC logic

Scenario 1: matching Daisycon view found

LEC returns status: "G"
The advertiser can store Daisycon as the network source for the configured post view window
The Daisycon conversion pixel can be considered if the user later converts

Scenario 2: no matching Daisycon view found

LEC returns status: "V"
No Daisycon post view marker is stored
The advertiser applies the agreed fallback logic

Scenario 3: another affiliate network is already known

A newer click from a competing affiliate network has already been stored
The LEC result should not overwrite that known network source
The advertiser applies the agreed network attribution rules

How LEC works

A typical LEC-based deduplication flow works like this:

A user sees a Daisycon banner on a publisher website
The banner is loaded from Daisycon servers
Daisycon registers the banner material request as view data
The user later visits the advertiser website directly
The advertiser triggers the LEC endpoint on the visitor’s client
LEC returns recent Daisycon event data for the campaign and device or browser, if available
The advertiser checks whether another competing affiliate network has already been identified
If allowed by the agreed priority rules, the advertiser stores or updates its own deduplication cookie
The user completes a conversion
The advertiser’s cookie switch setup determines whether the Daisycon conversion pixel should fire
Daisycon checks for a valid click first
If no valid click is available, Daisycon can evaluate the registered view for attribution

Step 1: Load LEC and store recent Daisycon activity

The advertiser triggers the LEC endpoint on the visitor’s client. If recent Daisycon view data is found, the advertiser can store Daisycon as the network source according to the agreed priority rules.

The lifetime of the advertiser-side cookie or marker should match the configured post view attribution window. It should not remain valid longer than the underlying view can be used for attribution.

Below is a simplified example of how such logic could work. This is not a Daisycon-provided script and should not be used as-is.

var currentNetwork = getCookie('network');
var script = document.createElement('script');
script.src = 'https://<tracking_domain>/js/lec/?ci=<program_id>';

script.onload = function () {
var response = window.__dc_response;

  if (response && response.status === 'G' && response.view) {
    if (!currentNetwork || currentNetwork === 'daisycon') {
      // Matching Daisycon event found
      setCookie('network', 'daisycon', configuredPostViewWindow);
      // Optional: store response.view.media_id for validation
    }
  }

  if (response && response.status === 'V') {
    // No matching Daisycon event found
    // Apply fallback logic
  }
};

document.head.appendChild(script);

Important: This example is only meant to explain the concept of using LEC in a deduplication setup. It is not a standard Daisycon script. In practice, the implementation may differ significantly depending on your website, tag management setup, consent setup, cookie switch logic, and other affiliate networks.

A matching LEC response should not automatically overwrite a known click from another competing affiliate network. LEC should supplement the advertiser’s existing deduplication logic.

Step 2: Apply the stored network value on the conversion page

On the confirmation page, the advertiser can use the same network cookie or attribution marker used by the existing cookie switch setup.

If the stored network value is daisycon, the Daisycon conversion pixel can be triggered
If another competing affiliate network is stored, the Daisycon conversion pixel should not be triggered
If no network value is available, the agreed fallback logic applies

LEC does not decide final attribution. It only helps the advertiser include recent Daisycon activity in its network deduplication setup.

When Daisycon receives the conversion, Daisycon checks for a valid click first. If no valid click is available, the registered view can be evaluated for attribution.

Using Google Tag Manager

Google Tag Manager can be used to trigger the LEC endpoint and use the result in cookie switch logic. The endpoint response should be translated into a cookie, variable, or data layer event that GTM can use.

Trigger the LEC request on the visitor’s client before the conversion decision is made
Read the response through window.__dc_response
Check whether another competing affiliate network has already been identified
Store Daisycon as the network source only when allowed by the agreed priority rules
Match the stored value’s lifetime to the configured post view window
Use the stored network source to control the Daisycon conversion tag
Define a fallback rule for cases where no recent event data is available

Do not use the LEC endpoint as a reporting source. It is intended for deduplication and technical validation.

Using LEC for technical verification

Technical publishers can also use the LEC endpoint to check whether a recent view has been registered for a specific campaign and their local device or browser.

After loading a Daisycon-hosted banner, the publisher can open the LEC endpoint for the corresponding campaign. A matching response can show the latest view date and the responsible media ID.

This is a secondary verification use. LEC does not provide full view statistics or impression reporting.

Fallback logic

You must decide how the cookie switch should behave if LEC returns no matching event or cannot be loaded.

Allow Daisycon tracking when no competing affiliate network is known
Do not allow any affiliate tracking when the source is unknown
Use another agreed fallback that is applied consistently across all competing affiliate networks

Fallback logic must be agreed before going live. Incorrect fallback logic can cause duplicate registrations or missed conversions.

Relation to LCC

LEC is related to LCC, but it solves a different problem. LCC stores the latest affiliate click source. LEC makes recent Daisycon event data available on the visitor’s client so post view attribution can be included in deduplication.

LEC can supplement an existing LCC setup. It should not overwrite a newer, known click from another competing affiliate network.

Important limitations

LEC is not a reporting API
LEC does not provide full view or impression statistics
LEC only checks recent Daisycon event data for the selected campaign and local device or browser
LEC does not replace the Daisycon conversion pixel
LEC does not decide final attribution by itself
A matching LEC result should not overwrite a newer click from another competing affiliate network
The advertiser-side marker should not remain valid longer than the configured post view window
Daisycon still checks for a valid click first when the conversion is received
LEC is intended for affiliate network deduplication, not for cross-channel attribution against other marketing channels

Consent and implementation responsibility

The advertiser is responsible for implementing LEC in a way that matches its consent setup, privacy policy, and applicable legal requirements.

If LEC is used to set an advertiser-side cookie or attribution marker, make sure this is handled according to the advertiser’s cookie and consent policy.

Step 3: Validate and monitor tracking

After implementation, test the complete flow before going live. This includes view registration, the LEC response, network priority, cookie lifetime, conversion tag firing, and fallback logic.

Testing checklist

Load a Daisycon-hosted banner and confirm that a recent view can be found through LEC
Test a situation where no recent Daisycon event exists and confirm that status: "V" is handled correctly
Check that a matching view does not overwrite a newer click from another competing affiliate network
Check that the advertiser-side cookie or marker is only set when expected
Confirm that its lifetime matches the configured post view window
Confirm that the Daisycon conversion pixel only fires according to the agreed deduplication rules
Test the fallback rule when no recent Daisycon event is available
Confirm that LEC is not used as a view statistics or reporting source

Conclusion

LEC makes recent Daisycon event data available on the visitor’s client. It is mainly used to support deduplication when post view attribution is enabled. LEC can supplement an existing LCC or cookie switch setup, but it should not overwrite a newer competing affiliate click. The advertiser-side marker must match the configured post view window, and LEC must not be used as a reporting API or general cross-channel attribution tool.