Privacy Policy

1. Who we are

gnlink ("gnlink", "we", "us", "our") is a link-management and marketing-analytics platform operated by Groovenexus Entertainment and Media Services Private Limited, headquartered at 189, Pratap Nagar, Mayur Vihar Phase 1, Delhi, India.

gnlink provides URL shortening and redirects, custom/branded domains, QR codes, a UTM builder, click and website analytics, conversion tracking, and optional connectors that send a customer's own conversion data to that customer's own advertising accounts (Google Ads, Meta) and data destinations.

We act in two different privacy roles depending on the data:

• Data controller for our own customers' account data (the marketers who sign up to use gnlink) — name, email, login credentials, billing details.
• Data processor / service provider for the end-user analytics data that our customers collect through gnlink on their own websites and links. Our customers are the controllers of that data; we process it on their behalf under our terms.

In short, gnlink acts as a data controller for its own account and usage data, and as a data processor on behalf of its customers for the visitor/conversion data they send through gnlink. A Data Processing Addendum (DPA) is available to business customers on request.

Contact: For any privacy question or to exercise your rights, email info@gn2.me, our privacy and data-rights contact.

2. The data we collect, and why

2.1 Customer account data (you, the gnlink user)

When you create and use a gnlink account we collect: your name, email address, hashed password, organization details, and — if you subscribe to a paid plan — billing information processed through our payment provider (Razorpay). We use this to provide the service, authenticate you, bill you, and communicate with you. We also keep security audit logs of account actions; the IP address in those audit logs is hashed, not stored raw (see §5).

2.2 Website & link analytics data (collected via our tracking tag and redirects)

Our customers install the gnlink tracking tag (gnTracker.js) on their websites, and route traffic through gnlink short links. Through these, gnlink collects behavioural and device metadata, not the contents of what people type. Specifically the tag collects:

• A first-party anonymous visitor identifier stored in a cookie named gnl_anid (a randomly generated UUID) plus a localStorage mirror. This lets analytics recognize a returning browser across sessions. It is a pseudonymous random id — it is not your name, email, or account.

  (Source: public/js/gnTracker.js getOrCreateAnonymousId(), lines 554–578.)

• Session cookies: gnl_session, gnl_session_start, gnl_last_activity (session stitching and timeout), and gnl_cid (a click token that links a click on a gnlink short link to on-site activity for attribution).

  (Source: getSessionId() lines 651–678; captureClickToken() lines 604–643.)

  By default these identity cookies are scoped to the registered root domain (eTLD+1) so a visitor is recognized consistently across a brand's subdomains; a customer can configure per-subdomain ("host-only") scoping instead.

  (Source: identityScope config, lines 129–160.)

• Pageviews (including virtual pageviews on single-page apps), clicks / element interactions, scroll depth, and page-performance timing.

  (Source: trackPageView() line 1116; trackElementInteraction() line 1275; setupScrollTracking() line 1093; trackPagePerformance() line 1440.)

• Device / environment metadata sent with a pageview: user-agent string, screen resolution, viewport size, colour depth, pixel ratio, timezone, and browser language.

  (Source: trackPageView() lines 1125–1132.)

• If a customer's Meta Pixel is present, the tag reads the customer's own first-party _fbp cookie (which their Meta Pixel set) to improve ad-match quality. gnlink does not set _fbp; it only reads it when already present.

  (Source: captureFbp() lines 586–595.)

What the tag does NOT collect from forms

gnlink's tracking tag does not capture what people type into forms. When a form is submitted, the tag records only metadata — the form's id/name/action, HTTP method, and a count of fields — and the field-value payload is hard-coded to null. There is no configuration flag that can turn value capture back on; the old value-reading code path was removed.

(Source: trackFormSubmission() — form_data: null, and the comment "the tag NEVER captures or transmits the values people type into a form", lines 1296–1316.)

For form-field interactions (to surface untracked lead forms in coverage reports), the tag records the field's type, name/id attributes (these are markup set by the website author, not user input), the parent form's shape, and a coarse value-length bucket (empty, 1-10, 11-50, 50+). The actual typed characters are never read — the length is measured and immediately discarded, and the exact length is never transmitted.

(Source: trackFormFieldInteraction() lines 1402–1438; _valueLengthBucket() lines 1367–1377; field_value_length_bucket.)

For embedded third-party vendor forms (HubSpot, Calendly, Typeform, Jotform), the tag listens only for the vendor's "form submitted" signal and extracts only the vendor name and a form/response id — never the invitee, submission values, or any typed field. This capture is gated on both the message shape and the sender's origin domain.

(Source: Layer B vendor capture, matchVendorSignal() lines 945–989; privacy guardrail comment lines 896–898.)

Purchase / conversion values

When a customer's site pushes a GA4-style purchase event to its dataLayer, the tag reads only an allowlist of value, currency, and transaction id — never email, name, address, or line items — to support revenue reporting.

(Source: Revenue-loop dataLayer capture, lines 1478–1485.)

Why we collect this: to provide our customers with click and website analytics, attribution (which link/campaign drove a visit or conversion), bot filtering, and conversion measurement — the core purpose of the product.

2.3 Retired data path (historical note — stated honestly)

A previous endpoint (POST /api/analytic/form-submission) once accepted anonymous form submissions including plaintext email/name/phone. This endpoint is retired: it now returns HTTP 410 Gone and writes nothing — no lead record, no analytics event, no PII.

(Source: src/server/route/AnalyticsEventApi.js lines 97–115.)

Honest retention caveat: historical lead rows created before retirement may still exist in customer databases and remain readable through the authenticated customer dashboard until a separate purge is completed.

3. Cookies and similar technologies

gnlink sets first-party cookies for identity and session continuity: gnl_anid, gnl_session, gnl_session_start, gnl_last_activity, and gnl_cid. They are set SameSite=Lax, Secure on HTTPS, and are first-party to the customer's own website (they are not third-party tracking cookies, and identifiers travel in the analytics request body, never as a cross-site cookie send).

(Source: cookie writers throughout gnTracker.js; e.g. lines 574–577, 651–678.)

We honour browser Do Not Track: when a visitor's browser sends a DNT signal, the tag disables tracking and does not mint or store any identity cookie.

(Source: checkPrivacyCompliance() / isDoNotTrackEnabled(), lines 347–365; identity is only established after this gate passes.)

The tag also supports a consent-required mode in which no tracking occurs until the visitor has given consent (detected via common consent cookies). Whether this mode is enabled is configured by the customer operating the website.

(Source: hasCookieConsent() lines 367–372; cookieConsent config line 165.)

Where required by applicable law, gnlink supports a consent-required mode and honors Do Not Track and site consent signals; customers are responsible for obtaining end-user consent in their jurisdiction.

4. Legal bases for processing (GDPR / UK GDPR)

Where GDPR applies, we (or our customers, as controllers) rely on:

• Contract (Art. 6(1)(b)) — to provide the gnlink service to account holders.
• Legitimate interests (Art. 6(1)(f)) — for pseudonymous analytics, bot filtering, and security/audit logging, balanced against the individual's rights.
• Consent (Art. 6(1)(a)) — where required for cookies/analytics under local law; the tag supports DNT and consent-gated modes to honour this.
• Legal obligation (Art. 6(1)(c)) — e.g. tax/accounting for billing records.

In summary, we rely on legitimate interests and/or consent as the legal basis, depending on the data category and jurisdiction.

5. IP address handling

gnlink does not store raw visitor IP addresses in analytics or audit records. On the analytics ingest path and in security audit logs, the IP is passed through a one-way, daily-rotating HMAC-SHA256 hash (truncated to 64 bits) before storage. The hash cannot be reversed to the original IP and rotates each day so it cannot link a visitor across days.

(Source: src/server/lib/utils/piiHashing.js hashIp() lines 56–70; called at AnalyticsEventController.js lines 685 and 1219, and model/AuditLog.js line 192.)

One deliberate exception: if a customer enables the Meta Conversions API connector, gnlink stores the raw visitor IP and user-agent on the specific conversion record, because Meta's API requires an unhashed IP as a match signal (a hashed IP is non-functional for Meta). These raw fields are:

• Marked select: false, so ordinary reads (dashboard, data export, GDPR export) never return them; only the Meta dispatcher can read them.

  (Source: model/Conversion.js lines 121–133.)

• Automatically scrubbed (nulled) once the conversion ages past Meta's 7-day event window.

  (Source: jobs/retentionCleanupJob.js META_RAW_PII_RETENTION_DAYS = 7, lines 32, 104–111.)

• Excluded from the data-export firehose allowlist.

  (Source: model/Conversion.js lines 122–123.)

6. Advertising connectors (data we send on a customer's instruction)

These connectors are opt-in per customer and send that customer's own conversion data back to that customer's own advertising accounts. gnlink never sends one customer's data to another customer's account, and never uses this data for our own advertising.

6.1 Google Ads (offline click conversions)

• The customer connects their own Google Ads account to gnlink via Google OAuth. gnlink requests a single scope — https://www.googleapis.com/auth/adwords — with offline access.

  (Source: googleOAuthClient.js ADWORDS_SCOPE line 36; buildConsentUrl() lines 135–154.)

• gnlink uses that access only to: (a) list the accounts the user can manage, so they can pick one; (b) read that account's conversion actions (to map a conversion) and its timezone (so conversion timestamps are correct); and (c) upload the customer's own offline click conversions (a Google click id gclid + conversion time + optional value/currency) to that account.

  (Source: listAccessibleCustomers() line 281; fetchConversionActions() line 300; fetchAccountTimeZone() line 330; googleAdsApiAdapter.js createSink()/postBatch() uploading to uploadClickConversions, lines 283–323.)

• gnlink never modifies campaigns, budgets, ads, keywords, or account settings. It only reads conversion actions/timezone and uploads conversions.
• No end-user personal identifiers are sent to Google in v1 — only the gclid, timestamp, and optional value. (Enhanced-conversion user identifiers are a deferred, empty allowlist in the code today.)

  (Source: mapConversionToClickConversion() — userIdentifiers deferred/empty, lines 131–133.)

• The Google refresh token is stored encrypted at rest using AES-256-GCM and is never logged, never returned in an error, and never exposed in any response.

  (Source: secretBox.js AES-256-GCM, lines 22, 45–60; secrecy comment googleOAuthClient.js lines 16–18.)

6.2 Meta Conversions API

• The customer provides their own Meta access token (pasted into gnlink), stored encrypted at rest (AES-256-GCM). gnlink sends only conversion events under a gnlink-namespaced event name.

  (Source: metaCapiAdapter.js header D4, lines 20–22; token used only as a request credential, never logged, lines 283, 297–298.)

• Personal identifiers, where present, are SHA-256 hashed before sending (email/phone are hashed; gnlink does not invent identifiers it does not have). The raw IP and user-agent are sent unhashed only because Meta's spec requires it, subject to the 7-day scrub in §5.

  (Source: normalizeAndHash() lines 91–96; mapConversionToCapiEvent() user_data allowlist, lines 141–160.)

6.3 CSV export for Google Ads

gnlink can also generate an on-demand offline-conversion CSV (gclid + time + value) for the customer to upload to Google Ads manually.

6A. E-commerce / Order Data (WooCommerce & Shopify store plugins)

Some of our customers are direct-to-consumer (D2C) merchants who install a gnlink plugin or connector on their online store — the gnlink Affiliate for WooCommerce plugin, or the gnlink Shopify integration — to measure which affiliate, link, or campaign drove a sale. When they do, the store sends order and refund data to gnlink. This section explains exactly what is sent, from where, why, and what is deliberately not sent.

6A.1 Our role and the purpose

gnlink is track-only. We measure and attribute conversions; we never process payments, never charge buyers, and never move money. The merchant is the data controller of their store's order data; gnlink acts as their data processor / service provider, receiving order data solely to attribute the sale to the correct affiliate, link, coupon, or campaign and to compute (but never disburse) affiliate commission.

The order data is received at gnlink's own fixed API endpoints and is never sent to any third-party URL. The plugin only ever calls the fixed gnlink base and authenticates with the merchant's own API key (Bearer token); no user-supplied URL is ever fetched, so there is no open-redirect / SSRF surface on this path.

• WooCommerce endpoints, verified: POST /api/v1/conversions/ecommerce and POST /api/v1/conversions/ecommerce/refund

  (Source: integrations/woocommerce/gnlink-affiliate/includes/class-gnlink-aff-api-client.php:5-11,50,195,261; ingest route gnlink-shortner/src/server/route/PublicApiV1.js:1352.)

6A.2 What order data is collected (and from where)

When a tracked order is paid, the store sends gnlink an order record containing only commercial / transactional fields — money amounts, product line items, coupon, status, and an anonymous click token. Specifically:

WooCommerce — order/conversion payload

(Source: class-gnlink-aff-order-mapper.php:97-142 build_body(), populated from class-gnlink-aff-conversion-sender.php:283-343 extract_order_data()):

• orderId — the merchant's own order id, used as the exactly-once idempotency key (order-mapper:106).
• currency — ISO currency code (:107).
• subtotal, discount, tax, shipping, total — order money amounts, rounded to 2dp and floored at 0 (:108-113).
• products[] — per line item: productId, quantity, unit price, line discount, and where available sku, name (product title), and category (product category name) (build_products :227-265; category resolved from the WooCommerce product category at conversion-sender:291-298).
• couponCode — the first applied coupon code, when present (:124-130).
• orderStatus — mapped to pending|processing|completed|cancelled|refunded (:119-122).
• paymentStatus — always paid in v1 (:116).
• occurredAt — the order creation timestamp, ISO 8601 (:137-139, from conversion-sender:323-328).
• clickToken — the gnlink click token (see §6A.4), when a tracked click preceded the order (:132-135).

Shopify — order/conversion payload

(Source: gnlink-shortner/src/server/lib/shopify/shopifyOrderMapper.js:152-197 mapOrderToConversionBody()):

• The same field set as WooCommerce: orderId (:157), currency (:159), subtotal (:163), discount (:164), tax (:165), shipping (:169), total (:178), products[] with productId/quantity/price/discount/sku/name (buildProducts :91-111), couponCode (:187-188), orderStatus (:184-185), paymentStatus:'paid' (:181), and occurredAt (:191).
• customerId is deliberately omitted — no Shopify customer id or buyer PII is forwarded (:145, :99 comment; the field is simply never added to the body).

6A.3 What order data we DO NOT collect (data minimization)

We do not collect buyer names, email addresses, postal/shipping addresses, phone numbers, or IP addresses through the store plugins. The plugins send order-level commercial data only — money amounts, product identifiers, coupon code, order status, and an anonymous click token. This is verifiable in the code: the WooCommerce order body builder (class-gnlink-aff-order-mapper.php:104-141) and its data-extraction source (class-gnlink-aff-conversion-sender.php:330-343) contain no customer name, email, address, phone, or IP field; the Shopify mapper explicitly omits the customer id (shopifyOrderMapper.js:145).

Note on the ingest endpoint's optional customerId. The gnlink e-commerce endpoint can accept an optional customerId from a merchant's own custom integration; when present, it is hashed server-side (SHA-256) and never stored raw (PublicApiV1.js:1371). Neither the WooCommerce plugin nor the Shopify integration sends this field, so in the plugin flow no buyer identifier — hashed or otherwise — is transmitted.

6A.4 The click token and the optional storefront pixel (gnl_cid)

Attribution joins an order to the click that drove it using an anonymous click token, not any personal identifier.

• The token is a random 128-bit hex value (32 hex characters) that gnlink's redirect appends to the destination URL and the tracking tag stores in a first-party cookie named gnl_cid (the cookie value is a small JSON object { token, ts }) (Source: class-gnlink-aff-click-token.php:24-60, cookie name :29, token shape :36).
• At checkout, the WooCommerce plugin reads gnl_cid from the cookie and stores the token on the order so it can be sent with the conversion (Source: class-gnlink-aff-conversion-sender.php:109-121). The token is a pseudonymous random value — it is not the buyer's name, email, or account.
• Optional storefront pixel (opt-in, default OFF). The WooCommerce plugin can, if the merchant explicitly turns it on and provides a valid tracking id, auto-inject the gnlink tracking tag (gnTracker.js) into the storefront so clicks are captured without hand-editing the theme. It is off by default and emits nothing unless enabled with a valid tracking id (Source: class-gnlink-aff-pixel-injector.php:71-90, opt-in guard :74-76). When enabled, the tag behaves exactly as the website tracking tag already described elsewhere in this policy (see the cookies and website-analytics sections), including honouring Do Not Track and consent-required mode.

6A.5 Refund data (including free-text refund reason)

When a merchant issues a refund on a tracked order, the store reports the refund to gnlink so the affiliate commission can be reversed (track-only — gnlink computes the reversal but never moves money).

WooCommerce — refund payload

(Source: class-gnlink-aff-order-mapper.php:174-217 build_refund_body(), from class-gnlink-aff-refund-sender.php:238-288 extract_refund_data()):

• orderId, refundId — the parent order id and the refund id (idempotency key) (:177-178).
• refundAmount — gross refunded amount (:180).
• refundSubtotal, refundDiscount — refunded item subtotal / discount, when derivable (:186-191).
• currency — the parent order's currency (:194-196).
• reason — the merchant's free-text refund reason, length-capped to 500 characters (:199-214, sourced from WooCommerce's refund->get_reason() at refund-sender:286).

Shopify — refund payload

(Source: shopifyOrderMapper.js:229-277 mapRefundToRefundBody()): orderId (:248), refundId (:249), refundAmount (:250), refundSubtotal when derivable (:263), currency (:268), and reason — the free-text refund note, capped to 500 characters (:272-274).

How we protect the free-text refund reason. The refund reason is free text typed by the merchant's own staff, so in principle a staff member could type personal data into it. To minimize that risk we take two measures:

• Automated scrubbing before sending. The WooCommerce plugin automatically removes obvious personal data — email addresses and phone numbers — from the refund reason before it is transmitted to gnlink. Only the scrubbed, length-capped text is sent (Source: GNLink_Aff_Order_Mapper::scrub_reason_pii() in integrations/woocommerce/gnlink-affiliate/includes/class-gnlink-aff-order-mapper.php:257-298, applied at :213 before the length cap).
• Merchant guidance. Merchants are advised, in the plugin settings/help, not to enter personal data in refund reasons. The scrub is a safety net, not a licence to include PII.

The scrub targets common, machine-detectable patterns (email addresses and phone numbers); it cannot guarantee removal of every possible free-text disclosure (e.g. a plain name), which is why the merchant guidance above also applies.

6A.6 Sharing and sub-processors for order data

Order/refund data received through the plugins is processed within gnlink's own infrastructure and is not sold. It is shared only with the same sub-processors that run the rest of the service (hosting/database, etc. — see the sub-processor list in §8) and only on the merchant's instruction. Order data is not forwarded to advertising platforms by these plugins (verified: the WooCommerce and Shopify mappers post only to the fixed gnlink e-commerce endpoints and to no ad-platform URL).

6A.7 Retention of order data

• Raw order / conversion & refund records (the order-level payloads described in §6A.2 and §6A.5) are retained for 24 months from the order date and then deleted.
• Derived commission statements and aggregate reports (which contain no raw buyer-linked order payloads — only computed totals, per-affiliate/per-campaign aggregates, and money figures) are retained for the lifetime of the merchant's account, because they are far less sensitive and are needed for the merchant's own commission accounting and audit history.

A merchant may request earlier deletion of their raw order data through gnlink's account data-erasure tooling (see §12); commission statements needed for the merchant's financial records are retained unless the account itself is closed.

6A.8 Data-subject rights for order data

Because the merchant is the controller of their store's order data, a shopper who wishes to access or delete data relating to their order should contact the merchant (the store operator); gnlink will assist the merchant as their processor. gnlink's existing authenticated data-export and erasure tooling (see §12) applies to the merchant's account, and raw order records in any case age out automatically at 24 months (see §6A.7). When a merchant relays a shopper's order-scoped request, gnlink will locate the relevant records by the merchant's order id (orderId, the idempotency key) and act on the merchant's instruction as processor.

7. Data export and data warehouse (bring-your-own destination)

Customers can export their own event data to their own storage:

• Bring-your-own S3-compatible bucket (NDJSON) or signed webhook destinations, configured per organization.

  (Source: model/ExportDestination.js — "BYO bucket / BYO webhook", lines 2, 40–41.)

• Because the destination endpoint is customer-supplied (untrusted input), gnlink applies SSRF protection: the destination host is resolved to an IP, private/loopback/metadata addresses are blocked in production, and the connection is pinned to the validated IP to defeat DNS-rebinding.

  (Source: s3Adapter.js SSRF/DNS-rebinding notes, lines 6–16, 31–54.)

• Access keys and webhook secrets for these destinations are stored encrypted at rest (AES-256-GCM).

  (Source: secretBox.js lines 1–17.)

• The export allowlist deliberately excludes raw IP/user-agent PII.

  (Source: model/Conversion.js lines 122–123.)

8. Sharing and sub-processors

We do not sell personal data. We share data only with:

• Sub-processors that help us run the service:
  • Razorpay — payment processing (billing).
  • Amazon Web Services (AWS) — cloud hosting and database infrastructure.
  • Google (Google Ads / Google Data Manager) — conversion uploads, only on a customer's instruction (see §6).
  • Meta — Conversions API conversion uploads, only on a customer's instruction (see §6).
  • Zoho Mail (Zoho Corporation) — our transactional email (SMTP) provider for account, verification, and system emails.
• Advertising platforms, only on a customer's explicit instruction and only that customer's own data, as described in §6.
• Legal/authority disclosures where required by law.

9. Data retention

• Analytics events / visitor identifiers: retained only as long as necessary for the service; the tracking tag's default retention target is 730 days, subject to each customer's configured retention policy.

  (Source: retentionCleanupJob.js — per-org retention policy with configurable defaults.)

• Raw IP / user-agent on Meta conversions: scrubbed after 7 days (§5).
• Account data: retained for the life of the account; after account erasure, PII is soft-deleted and anonymized after a 30-day grace period.

  (Source: retentionCleanupJob.js line 205; GdprController.js erasure, from line 280.)

• Historical pre-retirement lead rows: see the honest caveat in §2.3.
• E-commerce raw order / conversion & refund records: retained for 24 months from the order date, then deleted, subject to each merchant's configured policy and any earlier erasure request.
• Derived commission statements & aggregate reports: retained for the lifetime of the merchant's account (computed totals/aggregates only — no raw buyer-linked order payloads).

We retain each category of data only as long as necessary for the purposes described above and as required by applicable law.

10. Security

• Credentials and third-party tokens are encrypted at rest with AES-256-GCM, per-purpose keys, versioned for rotation.

  (Source: secretBox.js lines 1–24.)

• Visitor IP addresses are hashed on analytics and audit paths (§5).
• Tenant isolation: data is scoped per organization; ownership checks gate dashboard reads of lead/analytics data.

  (Source: authenticated, ownership-scoped routes, AnalyticsEventApi.js lines 117–131.)

• Outbound requests to customer-supplied destinations are SSRF-guarded (§7); connectors to Google/Meta post only to fixed, allowlisted hosts.

  (Source: assertAllowedHost in googleOAuthClient.js lines 84–90, metaCapiAdapter.js lines 209–215.)

• Passwords are hashed and access to production data is restricted. In the event of a personal-data breach, we notify affected parties and regulators without undue delay and, where required, within the timeframes mandated by applicable law (e.g. 72 hours under GDPR).

11. International data transfers

gnlink is hosted on Amazon Web Services (AWS) cloud infrastructure. For international transfers of personal data out of the EEA/UK, we rely on appropriate safeguards such as Standard Contractual Clauses where required. Google and Meta process the data sent via the connectors in §6 under their own terms and transfer mechanisms.

12. Your rights

Depending on your location, you may have the right to access, correct, delete, restrict, or port your personal data, to object to processing, and to withdraw consent. gnlink provides:

• Data access / export: an authenticated data-export (async ZIP) via POST /api/gdpr/export.

  (Source: GdprController.js requestExport, lines 130–167.)

• Erasure: account erasure that soft-deletes and anonymizes PII across collections.

  (Source: GdprController.js requestErasure, from line 280.)

For end users of our customers' websites: because our customer is the controller of that analytics data, please direct access/deletion requests to the website operator; we will assist them as their processor. To reach gnlink directly, email info@gn2.me. We aim to respond within the period required by applicable law (for example, within 30 days under GDPR).

You also have the right to lodge a complaint with your local data-protection authority.

13. Children

gnlink is a business/marketing tool and is not directed to children under the age of 16 (or the minimum age set by applicable law in your jurisdiction). We do not knowingly collect personal data from children. If you believe a child's data has been collected, contact info@gn2.me.

14. Changes to this policy

We may update this policy from time to time. Material changes will be notified via email and/or in-app notice, and the "Last updated" date above will change.

15. Contact

Privacy contact: info@gn2.me

Entity: Groovenexus Entertainment and Media Services Private Limited, 189, Pratap Nagar, Mayur Vihar Phase 1, Delhi, India.