Cookies that work for you, not against.

TenderPulse sets two categories of cookies. The first category is essential — cookies that keep you signed in and protect your account from cross-site-request-forgery attacks. Without them, the product cannot function. The second category is analytics — Google Analytics 4, loaded via Google Tag Manager, which tells us which pages and features you use so we know what to invest in. That is everything. There are no advertising cookies, no social media pixels, no session-replay tools, no behavioural profiling, and no fingerprinting.

This policy lists every cookie we set, explains why we set it, tells you how long it lives, and gives you the exact steps to remove or block any of them. We do not believe in burying opt-out instructions in a separate settings page behind three nested menus. If you want a cookie gone, this page tells you how — in plain language, up front.

This policy applies to tenderpulse.com.bd and its subdomains (dashboard.tenderpulse.com.bd). It does not apply to manage.tenderpulse.com.bd, our internal staff tooling — no analytics scripts load there at all.

We update this policy whenever we add a new cookie. New cookies appear in the inventory table in §2 before they are deployed. We do not silently introduce cookies first and update the policy later. If you want to verify this, the version string at the top of the page changes with every substantive update — you can compare it against your records.

Questions? Email help@tenderpulse.com.bd. We aim to respond within five business days.

The table below is the exhaustive inventory of first-party cookies set by TenderPulse. Every cookie is classified as Essential because each serves a function directly necessary to the security or operation of your account. We do not set any cookie categorised as “functional but non-essential,” “performance,” or “advertising.”

In addition to the first-party cookies above, Google Analytics 4 sets _ga and _ga_* cookies scoped to .tenderpulse.com.bd. These are third-party analytics cookies and are described fully in §3. They are the only third-party cookies on this site.

All first-party cookies are set with the HttpOnly, Secure, and SameSite=Lax attributes. This means they cannot be read by JavaScript running in the page, they are only transmitted over HTTPS, and they are not sent on cross-site requests that could be exploited for CSRF attacks.

We run Google Analytics 4 through Google Tag Manager to understand which pages and product features get used — so we know what to invest in next. It is configured with Consent Mode v2, which means:

• Analytics cookies: granted by default for measurement (page views, session duration, feature events).
• Advertising / personalisation cookies: denied by default — we do not run ads and do not share data with ad networks.
• Do-Not-Track: if your browser sends a DNT signal we automatically downgrade analytics consent to denied before any pixel fires.
• User identifier: when you are signed in we send a hashed version of your user ID to GA4 — never your email, name, or company name.
• IP address: GA4 anonymises IPs at collection; we do not store the raw IP in our analytics property.
• Internal admin (manage.tenderpulse.com.bd):excluded entirely. No analytics scripts load on staff tooling.

GA4 cookies (_ga, _ga_*) live for up to 13 months and are scoped to .tenderpulse.com.bd. You can opt out via your browser’s cookie controls or Google’s GA opt-out add-on.

The specific events we send to GA4 cover navigation (page views, scroll depth), feature interactions (tender search, AI copilot sessions, document uploads, export actions), and error events (4xx/5xx responses visible to the user). We do not send the content of your tender documents, search queries, copilot prompts, or any text entered into forms. Events are tagged with a session identifier and, when authenticated, a hashed user ID — never a plaintext identifier.

We do not use GA4’s Google Signals feature, which would link your on-site behaviour to your Google account for cross-site personalisation. Google Signals is explicitly disabled in our GA4 property settings. Our data retention setting in GA4 is 14 months — the minimum available — and we do not export raw GA4 data to BigQuery or any other destination.

Google’s Consent Mode v2 is the technical framework through which TenderPulse communicates consent decisions to Google Tag Manager before any measurement tag fires. Our implementation differs from the “consent banner + toggle” pattern common on e-commerce sites because we have taken a more restrictive default posture suited to a B2B procurement platform.

Advertising consent — permanently denied

The ad_storage, ad_user_data, and ad_personalization consent signals are set to denied unconditionally at page load — before Tag Manager initialises, before any tag fires, and regardless of any other user action. There is no consent banner, toggle, or preference panel through which a user can switch these to granted because we have no advertising infrastructure to enable. This is a product-level decision, not a temporary configuration: TenderPulse does not run advertising campaigns and does not share behavioural data with advertising networks.

Analytics consent — granted by default, overridden by DNT

The analytics_storage consent signal is set to granted by default for users who do not send a Do-Not-Track signal. This means GA4 can set its measurement cookies and collect aggregate usage data as described in §3. Our legal basis for this is legitimate interests — understanding aggregate usage of a professional procurement tool is a proportionate use of analytics data, and the data collected (hashed IDs, page paths, feature events, no personal content) does not carry meaningful privacy risk.

Do-Not-Track auto-downgrade

If your browser or browser extension sends an HTTP DNT: 1 header, our Tag Manager configuration reads this signal before any tag fires and automatically sets analytics_storage to denied. No GA4 cookies are set, no measurement data is collected, and no network requests are made to Google’s analytics endpoints for that session. This happens silently — you will not see a banner, and you will not need to find a settings toggle. The platform functions identically whether analytics is granted or denied.

Consent Mode v2 “basic” vs “advanced”

We use Consent Mode v2 in “basic mode” — tags do not fire at all when consent is denied, rather than firing in a cookieless/modelled mode. This is the more privacy-preserving implementation: when analytics consent is denied (via DNT or explicit browser blocking), Google receives no data from that session, not even the modelled pings that advanced mode sends.

We list what we do not use as explicitly as what we do, because on a procurement platform the absence of certain tools is as important as their presence. Tender data — bid prices, technical scores, BOQ figures, competitor intelligence — is among the most commercially sensitive data a firm produces. The following categories of tracking and analytics are permanently excluded from TenderPulse.

• No Facebook Pixel, no Meta SDK. No social-media tracker. We do not use any Meta product, SDK, or conversion API.
• No Mixpanel, Segment, Amplitude, Heap, FullStory, LogRocket, Hotjar. We do not use any commercial product analytics or session-replay tool. Replay tools are particularly dangerous for procurement data and we have decided permanently against them. A session-replay tool that captured your bid preparation workflow would record commercially sensitive information that could harm your competitive position — we will not run that risk even if a vendor claims their tool is “GDPR-compliant.”
• No advertising cookies. The product is paid and we do not run ads. Google Ads / DoubleClick / personalised- advertising features in GA4 are disabled at the property level.
• No fingerprinting. We do not run JavaScript that hashes your hardware, canvas, font, or other device characteristics to track you across sessions or devices without cookies.
• No cross-site tracking. We do not participate in any advertising network, data co-operative, or cross-site identity graph. Your TenderPulse usage data stays in our GA4 property and nowhere else.
• No A/B testing platforms with external data sharing. Any A/B testing we conduct is server-side, using our own infrastructure — no third-party experimentation SDK is loaded in the browser.

These exclusions are product decisions, not policy-layer commitments that can be quietly reversed at a future date. The absence of session-replay and advertising tools is enforced at the Tag Manager container level — there are no tags of these types configured, and new tags require a code change and deployment, not a Tag Manager publish. If we ever add a new analytics or tracking tool, it will appear in the cookie inventory in §2 before it is deployed, and we will notify you via in-app banner.

Beyond cookies, browsers provide other client-side storage mechanisms. We use one of these — localStorage — for UI personalisation. The others are not used.

• localStorage:we cache UI state (last opened tender, sidebar collapsed/expanded, theme preference) — no personal data, no tracking. This data lives only in your browser and is never transmitted to our servers or to third parties. It is not linked to your user account; clearing your browser’s site data resets it to defaults.
• IndexedDB: not used.
• Service worker / Cache API: not used.
• sessionStorage: used only within a single page session to hold ephemeral UI state (for example, which accordion tab is open). It is cleared automatically when the tab closes. No personal data is stored in sessionStorage.

Note that localStorage and sessionStorage data is not cleared by your browser’s “clear cookies” action. To clear this data you must use your browser’s “Site data” or “Local storage” clearing function — typically found under Settings › Privacy › Clear browsing data, with “Cached images and files” and “Site data” both selected. This does not affect your server-side account data in any way — only the local UI preferences stored in your browser.

Separately from cookies, our servers generate access logs for every HTTP request. This is standard practice for all web services and is distinct from cookie-based tracking. Server-side logging is not something your browser’s cookie controls can affect — it happens at the infrastructure level regardless of your cookie preferences. Digital Security Act 2018 §29

Each server log entry captures: your IP address, the HTTP method and request path (for example, GET /dashboard), the HTTP response status code, the timestamp, and your browser’s User-Agent string. We do not log request bodies (the content of your uploads or form submissions) in the access log. Request bodies are handled exclusively by the application layer under the data processing controls described in our Privacy Policy.

These logs are stored in request log service Logs in the approved Asia-Pacific region region for 90 days, after which they are automatically deleted by a CloudWatch log retention policy. We do not export access logs to any external analytics platform. Access to CloudWatch logs is restricted to on-call engineers for incident response and is protected by the cloud provider IAM role-based access control with MFA enforcement.

The 90-day retention period is the minimum we judge necessary for operational diagnostics and security incident response. The Bangladesh Digital Security Act 2018 §29 requires that service providers retain access logs for a minimum period for law enforcement purposes; our 90-day retention satisfies this requirement. We do not retain logs beyond 90 days for our own purposes, and we do not correlate access logs with GA4 analytics data to build individual user profiles.

For the full treatment of how we handle server-side personal data, including IP addresses as personal data under applicable law, see clause 2.8 of the Privacy Policy.

You have the right to control every cookie and storage mechanism described in this policy. This section gives you the exact steps — not vague references to “your browser settings.”

Browser cookie controls

Every major browser lets you view, delete, and block cookies on a per-site basis. To remove TenderPulse cookies:

• Chrome:Settings › Privacy and security › Cookies and other site data › See all site data and permissions › search “tenderpulse.com.bd” › Delete.
• Firefox:Settings › Privacy & Security › Cookies and Site Data › Manage Data › search “tenderpulse.com.bd” › Remove Selected.
• Safari:Settings › Privacy › Manage Website Data › search “tenderpulse.com.bd” › Remove.
• Brave:Settings › Privacy and security › Site and Shields Settings › Cookies and site data › See all site data and permissions › search and delete.

Deleting the better-auth.* cookies will sign you out. Deleting tp_consent_ack will cause the consent gate to re-appear on your next visit. Deleting tp_locale resets your language preference to the default. None of these deletions affect your server-side account data.

Opt out of Google Analytics

To opt out of GA4 measurement specifically, you have three options:

• Install the Google Analytics opt-out browser add-on — this works across all sites that use GA, not just TenderPulse.
• Enable Do-Not-Track (DNT) in your browser — we honour DNT and will not fire analytics tags when your browser sends the DNT: 1 header.
• Block *.google-analytics.com and *.googletagmanager.com at your DNS resolver or via a browser content-blocking extension (uBlock Origin, Privacy Badger, etc.).

Do-Not-Track (DNT) support

TenderPulse honours the DNT signal. When your browser sends DNT: 1, our Tag Manager configuration sets analytics_storage to deniedbefore any tag fires. No GA4 cookies are set and no data is sent to Google Analytics for that session. You do not need to take any further action to opt out of analytics if your browser is already sending DNT. To check whether your browser is sending DNT and to enable it if not: in Firefox, Settings › Privacy & Security › check “Send websites a Do Not Track signal”; in Chrome, Settings › Privacy and security › Cookies › Send a Do Not Track request.

Blocking essential cookies

You have the right to block or delete essential cookies too. If you block better-auth.* cookies, you will not be able to sign in to TenderPulse — the authentication system depends on them. If you block tp_consent_ack, the consent gate will appear on every visit. These consequences are a product of how session authentication works, not a penalty for exercising your rights. If you need to use TenderPulse in a privacy-strict browser context, contact us and we will explore what is possible.

We update this Cookie Policy whenever we make a substantive change to our use of cookies or other client-side storage — for example, if we add a new cookie, change a cookie’s purpose or lifetime, adopt a new analytics tool, or remove a tool that was previously listed.

What “substantive change” means. A substantive change is any change that affects the cookies set in your browser, the data sent to third parties, or the opt-out options available to you. Changes that do not affect these — for example, clarifying the prose, fixing a broken link, or updating a contact address — may be made without bumping the version string.

How we notify you. For any substantive change, we will: (a) update the version string at the top of this page; (b) update the inventory table in §2 to reflect the new state; and (c) display an in-app notification banner to all signed-in users for 14 days following the change. If a change adds a new non-essential cookie, the banner will clearly state what the new cookie is and link to the updated §2.

What we will not do.We will not introduce a new analytics tool, session-replay tool, advertising pixel, or fingerprinting script without notifying you in advance. We will not change the classification of an existing cookie from “Essential” to “Analytics” or vice versa without a banner notification. We will not introduce a new cookie in a production deployment before updating this policy — the policy is updated first.

Continued use as acknowledgement. Continued use of TenderPulse after a policy change is acknowledged to you via in-app banner constitutes acknowledgement of the updated policy. If you object to a change, you may opt out of the relevant cookie(s) as described in §8 or contact us at help@tenderpulse.com.bd to discuss alternatives.

Version history. The current version string is 2026-05-06.v2. Previous versions are retained internally and are available on request — if you need to know exactly what the Cookie Policy said on a specific date, email our privacy team and we will provide the archived version within five business days.

See also: Privacy Policy · Terms of Service · EULA · Trust Center