Cookie Policy

1. Who this policy is from, and what it covers

This Cookie Policy is issued by Sylvent Corporation, a Delaware corporation with its registered office at 131 Continental Drive, Suite 301, Newark, DE 19713, United States, trading as effect.com (“Effect”, “we”, “us”, “our”). Read together with our Privacy Policy, it forms part of our aviso de privacidad as a matter of Mexican law.

It covers every host we operate: the website at effect.com, the writing at blog.effect.com, and the client workspace at app.effect.com. You are asked once, on whichever host you reach first, and the answer you give is honoured on the other two without asking again.

Effect sells analytics software to non-bank lenders. We do not advertise, we do not sell personal information, and we do not share personal information for cross-context behavioural advertising. No control on this website switches advertising on, because there is nothing to switch on.

2. What a cookie is, in plain terms

A cookie is a small text file that a website asks your browser to keep and to send back on your next request. It is how a site recognises that two page views came from the same browser. Related technologies do the same job by other means: local storage and session storage keep values inside the browser without sending them automatically, and a pixel or beacon is a request whose only purpose is to report that something happened. Where this policy says “cookie” it means all of these, and section 7 says which is which.

A first-party cookie is set on our own domain. A third-party cookie is set on somebody else’s domain by content we placed inside our page. We can delete the first kind for you. We cannot delete the second kind, and we say so wherever it applies.

3. The categories we use

Four categories, and they are the standard ones.

Strictly necessary. Always on, never asked about. They make the site and the workspace work, they carry no measurement, they build no profile, and there is no version of this site that functions without them.

Analytics and performance. Counts how many people opened a page, how far down an article they scrolled, which control they pressed, whether a form was submitted, and how quickly the page rendered. It answers how many.

Session replay. Records mouse movement, scrolling and clicks during your visit, and builds aggregated heatmaps from many visits. It answers why a page works or does not. We keep this apart from counting and ask about it separately, because a replay of one visit is a materially larger amount of information about you than a tally is.

Embedded content from other websites. Content served by somebody else inside one of our pages. Today there is none: the booking calendar was the only one and it was removed on 3 September 2026, so this category currently applies to nothing. We keep the question on the card because the purpose still exists, and we would name a provider before placing one.

There is no advertising or targeting category. We set no advertising cookie, we run no remarketing tag, and advertising and personalisation signals are denied permanently rather than conditionally, whatever you answer.

4. Strictly necessary. Always on, never asked about

These make the site and the workspace work. Under Mexican and European rules they do not require consent, because they are what delivers the service you asked for.

They are: the cookie that keeps you signed in to the workspace; the cookie that carries a password-reset link for the hour it is valid; the anti-abuse check that runs on the sign-in and registration screens only; and the record of the answer you gave to this card.

Three of them exist only because you were asked a question. A record of a consent answer is the one category that never needs consent of its own: if it did, refusing would erase the proof of the refusal and you would be asked again on every page.

5. The three optional purposes

Everything that measures you waits for your answer. The card asks about three purposes, not three vendors, and you may grant one while refusing another. It is written that way on purpose: a purpose is a thing you can decide about, and a supplier is an implementation detail that changes without your decision changing.

Analytics and performance. Three services serve this purpose. They count page views, page changes made without a full reload, opening the demo panel and the wording of the control that opened it, which calendar you chose, file downloads, links out to other sites, the fact that a form was submitted together with its type and the page it sat on, and how quickly the page rendered. None of them ever receives a field you typed. Scroll depth is enabled in a tag-manager container rather than in our own code, which is why we describe it here rather than pointing you at a line in our repository.

Session replay. One service serves this purpose, and it runs on the marketing site only, never inside the client workspace. The contents of form fields are masked before anything leaves your browser.

Embedded content. One service serves this purpose: the booking calendar. Refusing it costs you the calendar and nothing else. A button in its place will fetch the calendar for that visit alone, without changing your stored answer, because asking to see a calendar is not the same as agreeing to be measured.

Before you answer, nothing has been contacted

Until you grant the purpose that carries it, a page of ours requests nothing from any of these providers and none of their cookies is written. Refusing changes nothing about that: after you press Reject, the only cookies you carry from us are the record of the refusal and the identifier that ties a future withdrawal to it, both named in section 7.

Who the providers are

The companies behind these three purposes are listed at effect.com/cookies/providers, with what each one does, which purpose it serves, whose cookie it is and where it processes. That list is kept current and changes without this policy being reopened. It is linked from the consent card as well as from here, so it is available to you before you answer rather than only after.

6. Three things that do not wait for your answer

We would rather name these than leave them out.

A record that a page was opened. When a page loads we record the path, the surface, and any campaign parameters in the address you arrived with. Without an analytics grant no identifier is attached and the subject is recorded as anonymous. This is not on the consent card because it stores nothing on your device: it is a single request from our page to our own server, and it is how we know whether anything we published was read at all.

Failure monitoring. When our own software fails, a technical error report is sent to a monitoring service so that we find out. It carries no field you typed. The monitor loads on every page so that it can catch a failure that happens while the page is still loading, which means it also sees the connection your browser makes to it, and that connection carries your IP address at the network layer.

The anti-abuse check on sign-in and registration. It receives your IP address and returns a token proving a person filled in the form. It receives no field you typed, and it runs on those two screens and nowhere else. It is not behind the consent card because it is what protects the sign-in itself.

7. Every cookie and storage key, by name

Named by what sets them and what they do. Where a cookie belongs to somebody else’s domain, the domain is given, because that is the accurate description of whose cookie it is and it is what you would see in your own browser.

Strictly necessary, on our domain

sb-<project>-auth-token

Keeps you signed in to the workspace. Host-only, HttpOnly, Secure, SameSite=Lax. Up to 400 days, the lifetime of the refresh token it carries.

effect_reset_open

Carries a password-reset link while it is valid. HttpOnly, host-only, 60 minutes, deleted the moment the reset completes.

effect-consent

The answer you gave. 365 days, with a copy in local storage.

effect-consent-id

Ties a later withdrawal to the answer it withdraws. 365 days.

effect-internal

Marks a browser as ours so our own visits are excluded from counting. 365 days.

Analytics and performance, granted by you

_ga, _ga_<id>

On our domain. Tell one browser from another so visits can be counted, and hold the session state for the single analytics property we run.

A browser identifier for product analytics

On our domain, with the same value kept in local storage under the same name and three further keys in session storage.

A performance measurement

Writes nothing to your browser at all.

effect-ft

On our domain. Records the campaign you first arrived from, so that a later enquiry can be attributed to it. 365 days, written only if you granted analytics.

Session replay, granted by you

_clck, _clsk

On our domain. Tie this browser to its replay identifier so repeat visits are recognised, and hold the state of one recording session.

CLID

On the replay provider’s own domain.

MUID

On the provider’s own domain. A browser identifier set by that provider’s service rather than by us.

Two of these four are on our domain and we can clear them. Two are on the provider’s own domains and we cannot. Section 8 says exactly what changes when you withdraw.

Embedded content, granted by you

Nothing sets these any more. Until 3 September 2026 the booking calendar and its own providers set them from inside the calendar’s page, on their own domains: an anti-bot check (__cf_bm), a persistent visitor identifier and its session half (_sp_id.<id>, _sp_ses.<id>), and a device signal (m). They are named here so that a cookie already stored in your browser can still be identified and cleared; we received nothing from any of them then and receive nothing now.

8. Changing your mind, and exactly what changes

You can change your answer at any time from the Cookie preferences link in the footer of any page, or from the same control inside the workspace.

What happens immediately. Consent signals are set back to denied. The analytics tag stops. The product analytics library records the opt-out and stops. The performance measurement stops. The replay recorder is sent both documented signals, which end the current recording and stop the next one. The calendar is replaced by a button.

What we can clear, and what we cannot. The cookies we set ourselves, the first five named in section 7, we delete, and the first-touch mark goes as soon as you take the analytics purpose away. The measurement services keep cookies of their own, some on our domain and some on theirs. Those we do not delete: what reaches them is the stop signal each one publishes, and being told to stop is not the same as being erased. Section 7 names every one of them, and clearing site data in your browser removes the ones our own domain holds. We would rather set this out than promise a clean erase we do not perform.

Withdrawal is recorded, not erased. Withdrawing writes a new consent record. It does not delete the previous one, because the previous one is the proof of what you agreed to and when.

Deleting what we stored on this browser. Alongside the answer buttons, the card carries a control that removes, from this browser, your answer, the identifier that carries it and the first-touch mark. It tells you afterwards what it removed and names anything it could not reach. Your browser then returns to the never-asked state and you are asked again on your next visit. Two things this does not do, and we would rather say so than let you assume otherwise: it cannot reach cookies on another company’s domain, which are named in section 7, and it does not delete consent records already written, because those are the proof of what was agreed and when. Removing those is a rights request under section 10 rather than a button.

9. The record of your answer

We keep, against each answer: which purposes you granted or refused, when, the version of the wording that was on screen at the time, and the technical details needed to make the record meaningful, which are the IP address the answer came from and the browser string. That date is recorded against your answer, so a decision can always be read against the words that were on screen when it was made.

Consent records are kept for three years and then removed.

10. Your rights over what is described here

If you are in Mexico, the ARCO rights (acceso, rectificación, cancelación, oposición) apply to the data described here, and the procedure for exercising them, including who to write to and how long we take to answer, is set out in the Privacy Policy under “Your rights”. If you are in the European Economic Area or the United Kingdom, the rights of access, rectification, erasure, restriction, portability and objection apply in the same way. If you are a California resident, you have the rights to know, delete and correct, and the right to opt out of the sale or sharing of personal information, which we do not engage in.

11. Changes to this policy

We may update this policy. The updated version is posted with a new “Last updated” date and, where the change is material, with additional notice.

The provider list changes separately, and that is deliberate. Adding or replacing a supplier changes who is behind a purpose; it does not change what the purpose is or what you agreed to. Changes to that list are published at effect.com/cookies/providers with the date of each change, and you can subscribe there to be told when it changes. Where a change means a purpose starts doing something materially different from what you agreed to, we ask you again rather than relying on this paragraph.

12. Contact

Sylvent Corporation, 131 Continental Drive, Suite 301, Newark, DE 19713, United States.

For anything in this policy, including a request to exercise a right over the data it describes: legal@effect.com. For general enquiries: info@effect.com.