/handbook/headless-wordpress/discovery-framework/
What We Do
Digital Platform MigrationsKey SolutionsManaged ServicesStaffing SolutionsIndustriesProducts
Discovery
Strategic consultancy & project roadmap
Growth Services
On demand development & consultation
Site Maintenance
Annual maintenance. Done for you
QE Services
Testing across SDLC for assured quality
Hosting Migration
Move to a performant hosting with zero downtime
WooCommerce
Enterprise commerce delivered without lock-in
AI
Unlock real use cases and integrations
All Services
A suite of services for any need
Technology STACK
eCommerce
Scale your e-commerce with WooCommerce, integrations, and custom extensions for growth.
EasyEngine
Server management tool that makes using WordPress on Nginx easy.
Web Auditor
Performance Audit & Insights for your Website.
rtMedia
A complete media management plugin for WordPress.
Resources
About Us
CLEAR
Resources When to go Headless? How to run a Headless discovery
Topics
On this page
- When to go Headless?
- rtCamp’s philosophy & principles
- How to run a Headless discovery
- Key concepts & terms
Strategic Alignment – Why are we building this?
1. Define “Success” and Long-term Value
2. Identify Key Stakeholders and Workflows
3. Understanding Risk and Security Governance
Technical Blueprinting – How will we build this?
System & Data Architecture
Tech Stack
Human Resources – Who can build (and maintain) this?
rtCampers
Client Teams
Defining Responsibilities & Handoff
Last updated on Apr 1, 2026
How to Run a Headless Discovery
While a thorough discovery phase is vital to the success of any project, its importance is magnified for Headless WordPress. Our ability to understand and accurately estimate project requirements serves two purposes:
- It’s what ensures that Headless WordPress is a viable – and cost-effective – strategy that is capable of answering the client’s needs.
- Even more importantly, it’s what ensures that we can deliver on those goals and avoid costly and compounding mistakes during all phases of the project.
This article provides a framework to guide these critical discovery conversations,highlighting what information we are trying to capture and how we translate that into specific requirements.
To ensure a comprehensive evaluation, we structure the process around answering three fundamental questions – in order. First, Why are we building this in Headless WordPress? Second, How will we build it? And finally, Who will be needed for which aspects of the project.
Strategic Alignment – Why are we building this?
Before a single line of code is written, we must establish the strategic foundation of the project, anchoring it to concrete, measurable business goals. Only then can we see if Headless is even a viable tool to reach them.
ℹ️ Note
Building strategic alignment for Headless WordPress projects varies little from Traditional WordPress projects, but can have outsized implications. The following is not intended to replace other discovery materials, but rather highlight those that tend to have the greatest impact.
1. Define “Success” and Long-term Value
A project is only successful if it delivers tangible value to the client’s business. Our first task is to work with the client to understand and define what success looks like and how it will be measured.
Project KPIs
Clients often start with vague goals like “we want it to be faster” or “we need more flexibility”. Our responsibility is to drill into these statements and connect them to measurable business outcomes. For example:
- If the goal is performance, will success be measured by an X% improvement in CWV, a Y% increase in conversion rates, a Z% reduction in server costs, or even a measurable decrease in user-reported complaints?
- If the goal is omnichannel content, will success be defined by a reduction in workflow steps for syndication, updating templates and responsiveness so content is supported across more screens and mediums, or launching an entirely new web/mobile/AI app/user experience?
From a Headless WordPress perspective, the individual Project KPIs set are (comparatively) less important than the type of KPI chosen, as the question we must ask is two-fold:
- First, is Headless WordPress even a tool that can be used to achieve this type of goal?
- Next, what are the cost-benefits of using Headless WordPress to achieve this goal versus traditional WordPress?
Total Cost of Ownership (TCO)
Headless architecture requires different – potentially higher – operational costs – and depending on the level of separation of concerns or other engineering or deployment considerations, more complex deployment pipelines, and different maintenance requirements than traditional WordPress.
At the same time, all enterprise clients have different cost sensitivities, measurements, infrastructure requirements and more. For some clients, an increase in deployment costs can be offset by a reduction in work-hours by content writers or in-house developers. Other companies may have strictly siloed cost centers, which will require a different ROI measurement to be able to justify the additional costs for Headless WordPress.
Scaling and Roadmapping
Beyond immediate ROI, some of the strongest business cases for headless – or against – are found in the client’s long-term vision. A project that may seem simple enough for traditional WordPress might be the first step in a multi-year strategy that would be difficult or impossible to execute on traditional architecture.
Our goal is to uncover these future plans to ensure we are building a foundation that enables, rather than obstructs, future growth. We’re listening for concrete strategic initiatives, not just vague possibilities. The key questions to ask are:
- What is the 3-5 year vision for this platform? Probing this helps us understand the true scope of ambition. Are they just maintaining the site, or will they be actively expanding or experimenting with different functionality and features.
This question also allows us to unearth other potential risks and hidden dependencies: who will be responsible for updating and maintaining the platform.
- What is the expected lifespan of this project before the next major rebuild?
A headless architecture is a significant investment, whose costs are best absorbed over the lifespan of a project. If the client anticipates a full redesign in less than three years, the long-term architectural benefits may not have time to materialize, weakening the case for the higher upfront cost.
At the same time, adopting Headless can actually be a strategy to increase project reusability and lifespan. In the previous example, an intentional separation of concerns could reduce the costs of a redesign significantly, by reusing the parts of the project successfully decoupled from the frontend’s “design”.
-
Are there plans to syndicate this content to other channels? This is a classic justification for Headless. Look for specific plans for:
- Native mobile apps (iOS/Android)
- In-store displays, kiosks, or IoT devices
- AI-powered chatbots or voice assistants
- Third-party sites or partner portals
-
Are there plans for significant audience scaling? Features like i18n for multiple languages and regions can be managed more effectively with a decoupled architecture and/or one involving multitenancy.
More important than the potential benefits, however, are the potential costs. Architectural decisions made early to account for scaling are much cheaper than having to rework fundamental parts of the application to scale or be distributed efficiently.
2. Identify Key Stakeholders and Workflows
A successful project is one that serves the people who use it every day. Identifying the key stakeholders is crucial, but it’s even more important to understand their goals, their frustrations, and their critical workflows. A feature that looks great on paper is a failure if it disrupts a business-critical process or is unusable by the team meant to manage it.
In a Headless project, the implications are magnified. Our separation of concerns means we have to be even more intentional about creating a cohesive and frictionless experience – for all stakeholders.
Key Stakeholders
We need to identify the needs of several key groups, and understand both their processes and what they need from the new platform to be successful. The following is a non-comprehensive list:
-
Content Managers and Editors: This is the most important group to understand, as it determines what WordPress functionality we will need to support their workflows. In addition to the usual discovery questions, we need to understand:
- How important is WYSIWYG or live/near-live preview of the site as they edit?
- Do they rely on specific features of plugins Yoast SEO or ACF for their daily work?
- How much autonomy do they need to create new pages and layouts, or change existing designs, without developer intervention?
-
Marketers / Managers: These individuals are the primary drivers of website changes, and rely on tooling and data to inform both website and company strategy.
- What automation and analytics platforms are essential for their work? (E.g. HubSpot, Google Analytics)
- What features and workflows can make their jobs easier? (e.g. Split Testing, custom data-admin views, context sources for AI)
-
In-house Developers: For some clients, we provide the framework upon which they can build and grow themselves. Mapping the needs of those assigned to work on the project (or those of their employer) ensures they can actually use the solution we build.
- How are development teams currently structured? (E.g. frontend/backend, full-stack, outsourced)
- What parts of the application will they be expected to develop / maintain without our expertise?
- What specific skills, language, or knowledge do they have, and what training are they expected to undergo.
-
End users: Ultimately, a website is a tool meant to convert and serve your end-users, and it’s their needs and expectations that will determine if there are specific user experiences that require a solution outside the domain of Traditional WordPress.
- Who are they, and what are their primary goals when interacting with the platform?
- What are their pain points with the current system, and what improvements would enhance their experience?
- What are their expectations regarding performance, usability, functionality, and accessibility?
Key Workflows
Beyond identifying the people, we must map how they work together. Workflows are sequences of tasks that often involve multiple stakeholders, and in Headless WordPress we must take care when these tasks cross the boundaries between
various concerns or domains.
Mapping these processes are also critical for defining requirements for user roles, permissions, integrations, providing value beyond just identifying points of friction.
For example:
-
Content Publication & Approval: This is the most fundamental workflow for any CMS, and it’s essential we get it right:
- What are the exact steps from a draft to a published post? Does it require a multi-step approval process?
- How will approvers preview content? Since the frontend is a separate application, a seamless preview experience requires deliberate architectural planning. This is a non-negotiable discovery question.
-
Legal & Compliance: The process of ensuring compliance can be more complex in a headless environment. As with understanding and managing our sources of truth, we need to clearly understand our client’s requirements in these areas at the outset of the project:
- A11y: For example, what level of WCAG is required; is this enforced solely via frontend theme/template or also the responsibility of the content management team?
- Privacy (GDPR/CCPA): If a user submits a “right to be forgotten” request, what data – WordPress or otherwise – needs to be covered?
- Cookie Consent & Tracking: What level of tracking and consent is required? We’ll need this to decide how and where it’s tracked and managed.
3. Understanding Risk and Security Governance
While standard security practices still apply, a headless architecture introduces new surfaces and systems that should be taken into account. Our goal is to identify unique risks that can be mitigated – or exacerbated – by going Headless.
- API Security & Exposure: The connection point between the WordPress backend and the frontend, is an entrypoint that needs to be managed. We need to understand if (parts of it) will be publicly accessible or limited to specific apps, and enforce policies and enable protections accordingly.
- Authentication & SSO: Beyond determining the source of truth responsible for user roles and permissions, we need to understand what authentication flows are required and where users are expected to be authorized.
- HIPPA, GDPR, EU-VAT or other compliance-specific requirements may govern where data is stored, how it can be accessed, how and how often it must be audited and more. Headless WordPress gives us more tools to address these needs flexibly, but the only existing solutions are bespoke.
Technical Blueprinting – How will we build this?
With a clear understanding of a project’s strategic goals, we can begin to design the technical solution. The decisions made here directly align to the requirements established by the previous section.
ℹ️ Note
The purpose of this section is not to teach you what specific features should be implemented in response to specific client needs – nor how. We have engineers for that.
Rather, the goal is to provide a brief overview of the potential costs and implications of various solutions for addressing certain common user needs, and help you to evaluate which is ideal for a specific project.
System & Data Architecture
When we’re lucky, we get to define the overall structure of the system and the flow of data within it, and then choose the optimal framework, tools and hosting providers. More commonly, the client has a particular host or framework in mind, and we must choose the best options from within those confines. Regardless of approach to reach them, the concerns and requirements are usually the same:
- What are the sources of truth? Both the type and number of sources of truth can be an indicator of whether a project would be a good candidate for Headless WordPress. Mapping these clearly also shows us what level of skill is required to implement and maintain them in our project.
- What separation of concerns will be enforced? We also must consider what boundaries and responsibilities we use to enforce our data flows and sources of truth, such as different repos, separate databases or hosts, or even external services. Be it through scaffolding, CI/CD workflows, or training, efforts to maintain these separations must be justified by the value we can capture from them over the project’s lifetime.
- What are the technology preferences or constraints? We need to identify any existing technical requirements or preferences from the client and even from our internal teams, as these can be significant constraints. It’s important to distinguish between a “hard requirement” (e.g., “we must host on our existing WPVIP account”) and a “soft preference” (e.g., “our team has some experience with Vue.js”). Understanding their reasoning helps us guide them to the best solution, rather than just accepting a preference that may not be a good fit.
Tech Stack
Once we’ve understood the high-level architectural constraints, we can select the specific tools for the job. The goal is here is two-fold:
- To meet the project’s functional requirements while respecting the client’s budget, technical expertise, and long-term maintenance capabilities – same as a traditional WordPress project.
- To demonstrate whether the use of Headless WordPress provides concrete value in comparison to a traditional WordPress project.
We recommend aligning that value with the previously established project KPIs.
Frontend Considerations
Frontend requirements are likely the biggest driver of Headless WordPress projects, and arguably the most significant technical decision that needs to be made. If we’re not using traditional WordPress, we need to make sure that the alternative we’re choosing is better.
- How dynamic is the content? Sites with highly personalized or real-time data (e-commerce, user dashboards) are harder to scale in Traditional WordPress, where you’re mostly limited to aggressive forms of page or object caching, than they are in Headless WordPress. If you’re building a Headless site that handles mostly static content, you’ll want to make sure your front supports some form of Static Site Generation and has a smart deployment strategy to keep build times low.
- What are the UX Requirements? The answer to this question is the most common justification for Headless WordPress, as there are just some user experiences that cannot be done effectively in Traditional WordPress. Specific UX requirements along with what expertise is available to the project is what will determine which frontend stack to choose.
Backend & Deployment Considerations
In a headless project, we are managing a distributed system, not a single website. The strategy for how we host, deploy, and connect these separate applications is critical for performance, stability, and long-term cost of ownership.
- How will the application(s) be hosted? The most common pattern is to use specialized, separate hosts for the frontend and backend (e.g. WordPress on WPVIP, the frontend on Vercel), however this pattern increases vendor complexity and operational costs. The best solution will weigh the benefits of different strategies against the client’s budget and workflows, and internal capabilities.
- What is the delivery workflow? We need to define a CI/CD pipeline that implements and automates our best practices, as well as other deployment concerns. For example, a site might need to trigger a rebuild only when specific content types are updated, and otherwise rely on client-side fetching.
- What scaling/deployment features are needed? Solutions like CDN, multitenancy, edge-caching, key-value stores, o11y, and more, require initial time and skill to set up correctly, and can be costly to implement effectively later on in the project if not accounted for. As rtCamp builds a larger library of prior art and standardizes around specific solutions, the importance of these considerations will be reduced.
Feature and Ecosystem Considerations
A headless architecture fundamentally changes how we approach features. Functionality that was once a single “install and configure” plugin now requires a deliberate integration strategy. We must evaluate every feature—from forms to search—to determine where the work needs to happen: in the WordPress backend, on the frontend application, or both.
For WordPress plugins, we must be wary of plugins that output their own HTML, CSS, and JavaScript. Plugins usually can be audited as follows:
- Backend-Only plugins: These generally work with little to no modification. Plugins for duplicating existing posts, optimizing uploads, exposing new admin screens, etc operate within WordPress and don’t have an impact on the API.
- Data-Providing plugins( E.g. ACF, Yoast SEO): These plugins primarily define and store data. If we need access to their data, we need to verify it is exposed for – or alternatively secured from – the API. In many cases, pre-existing helper plugins can reduce the up-front costs for a minimal addition of tech-debt.
- Frontend-rendering Plugins (E.g. Gravity Forms, WooCommerce ): This category requires the most work. Since we can’t always reuse the PHP-based frontend output we need to rebuild their functionality in our application using the data they provide. The cost of supporting a single, complex plugin can be significant and must be scoped as a major feature; however through use of composable and reusable patterns, efforts to support popular plugins can be successfully diminished across multiple clients.
Third-Party Integration Considerations
A key strength of Headless is the ease of integrating modern, API-first services. While we may have already determined what the sources of truth should be, we still need to determine where the integration should occur.
- Frontend-only integrations are the easiest to implement. As long as the integration has a well-documented API, then we can bypass many architectural considerations, and rely mainly on tooling and testing automation to ensure the integration continues to work.
- Frontend-led integrations are when the data is sourced via the frontend, but then converted and sent to WordPress for later use. You can see an example of this in most headless “Stripe” implementations, where the frontend APIs will communicate with Stripe to process the order, and then will update WordPress User meta based on the results.
This pattern places more complexity on the frontend team, while minimizing the WordPress knowledge and surface area required to maintain the project. - Backend-led integrations are more robust for complex or sensitive data. These will usually be handled by a Features plugin if an existing WordPress integration doesn’t exist. By funneling data via WordPress, you increase the backend complexity both to get the data into and out of WordPress, but open up more opportunities for security and performance while simplifying frontend logic and audit procedures – since integration data is handled the same as other WordPress data.
Human Resources – Who can build (and maintain) this?
The success of a Headless WordPress project depends as much on the people as the technology. It doesn’t matter how elegant the technical solution is if the team cannot effectively build, use, or maintain it. This final section focuses on assessing the capabilities and responsibilities of all teams involved.
rtCampers
While the goal of this article – and the Headless Handbook in general – is to lower the barriers of entry and knowledge requirements for a successful Headless WordPress, at the moment they still remain fairly high. It isn’t just enough to ensure that we have a senior engineer to review the requirements collected during discovery and propose a technical specification, the spec itself needs to be written based on the projected availability of developers during the project.
Until we are better equipped to capture and reuse existing headless work, senior developers with experience specific to project’s needs are essential during all phases of the project – even if just to review and approve technical plans and implementations. If we cannot provide that, it is an indication to revisit our Headless stack – or even our choice to use headless altogether.
Client Teams
Beyond identifying stakeholders and understanding their workflows, we need to probe their technical comfort and expectations. If the client has no developers proficient in the chosen frontend framework, they will be entirely dependent on us for every future modification, or require extensive training. Knowledge, skills, and even the amount of time the client is willing to allot to these tasks can restrict or even invalidate a technical proposal.
Defining Responsibilities & Handoff
A successful handoff depends on drawing unambiguous lines of ownership. This prevents the long-term risk that comes from assuming someone else is responsible for a critical part of the system. For Headless WordPress projects, this serves the additional role of ensuring that all necessary skills are accounted for.
During discovery, we recommend creating a specific “persona” for the Directly Responsible Individual (DRI) for every component of the project before assigning any specific individual or team to the position. This goes beyond the codebases to include hosting accounts, third-party service subscriptions, domain management, and security monitoring, and any other intricacies unique to the project.
The resulting Skills/Responsibility matrix will become the foundation of the maintenance plan and serve essential to both resource allocation for development and the specific documentation and training required for a successful handover.
rtCamp’s philosophy & principles
PREVIOUS
Credits
David Levine
Author
David Levine
Author
David Levine is a Senior WordPress Engineer and Product Lead at rtCamp with a background that few engineers in the WordPress space can claim. A WordPress Core Contributor across multiple releas…
Good Work. Good People.
Industry partnerships
Compliance certifications
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Company
Solutions
Subscribe to our newsletter and get a few email updates every month.
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Cookie Consent
We value your privacy
We use cookies to give you the best possible experience. By clicking “Accept,” you consent to our use of cookies to improve site functionality, analyze usage, and personalize content and communications. Your privacy matters to us, and we are committed to handling your data responsibly and transparently. Please check our Privacy Policy for more details.
Manage PreferencesDon’t AllowAllow All
Why do we use cookies?
×
By clicking "Accept" or "Decline All" at the bottom, you consent to the use of cookies and other tools as described in our Cookie Policy in accordance with your settings and accept our Terms of Service.
Toggle EssentialEssential
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Geolocation Config
This cookie is used to store the consent settings based on the visitor's location.
30 days
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
Toggle CloudFlareCloudFlare
CloudFlare provides web performance and security solutions, enhancing site speed and protecting against threats.
Service URL: developers.cloudflare.com (opens in a new window)
Name
Description
Duration
cf_clearance
Whether a CAPTCHA or Javascript challenge has been solved.
session
Toggle CommentsComments
These cookies are needed for adding comments on this website.
Name
Description
Duration
comment_author
Used to track the user across multiple sessions.
Session
comment_author_email
Used to track the user across multiple sessions.
Session
comment_author_url
Used to track the user across multiple sessions.
Session
Toggle GodamGodam
GoDAM" is primarily a specialized WordPress plugin and media management service designed to enhance video hosting, marketing, and asset management directly within the WordPress dashboard.
Service URL: godam.io (opens in a new window)
Name
Description
Duration
user_image
Temporarily stores the path to the user's avatar or profile picture for quick rendering in the website header.
session
user_id
Stores the numerical ID of the logged-in user to maintain session continuity and basic site operations.
session
full_name
Stores the logged-in user's display name to personalize the site interface without needing database queries.
session
system_user
First-party cookie used to store basic application state identifying the current system user role.
session
sid
A generic session ID cookie used to maintain user state and functionality as the visitor navigates through the site.
session
Toggle Google reCAPTCHAGoogle reCAPTCHA
Google reCAPTCHA helps protect websites from spam and abuse by verifying user interactions through challenges.
Name
Description
Duration
_GRECAPTCHA
Google reCAPTCHA sets a necessary cookie (_GRECAPTCHA) when executed for the purpose of providing its risk analysis.
179 days
Toggle Google Tag ManagerGoogle Tag Manager
Google Tag Manager simplifies the management of marketing tags on your website without code changes.
Name
Description
Duration
cookiePreferences
Registers cookie preferences of a user
2 years
td
Registers statistical data on users' behaviour on the website. Used for internal analytics by the website operator.
session
Toggle StatisticsStatistics
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Toggle Factors AIFactors AI
Factors.ai is a B2B account intelligence and marketing analytics platform that helps Go-To-Market (GTM) teams identify anonymous website visitors, track buyer journeys, and measure the ROI of marketing campaigns.
Service URL: www.factors.ai (opens in a new window)
Name
Description
Duration
_fuid
It is sent to capture session details and track user behavior across your website to provide behavioral data and intent signals.
1 Year
Toggle Google AnalyticsGoogle Analytics
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Service URL: policies.google.com (opens in a new window)
Name
Description
Duration
FPGSID
Stores a session or user identifier to track how visitors interact with a website. This helps Google Analytics measure website performance, user engagement, and usage patterns.
Session
FPLC
Used by Google Analytics to link visitor interactions and sessions across multiple related domains.
20 hours
FPID
A server-side Google Analytics cookie used as an alternative user identifier when third-party cookies are restricted.
2 years
_ga
ID used to identify users
2 years
_ga_
ID used to identify users
2 years
Toggle Jetpack StatsJetpack Stats
Jetpack's built-in visitor analytics. It records page views, referring sites, search terms, and outbound link clicks, and also carries the shared visitor-tracking library used by Jetpack Instant Search and WooCommerce Analytics.
Service URL: automattic.com (opens in a new window)
Name
Description
Duration
tk_aip
Stores a list of anonymous visitor IDs so they can be merged into one identity once a visitor is recognized.
Up to 5 years
tk_tc
Used once per page load to work out which cookie domain the Tracks library should use, then removed as soon as it's read back.
Session (deleted immediately after use)
tk_qs
Queues analytics events for Jetpack's Tracks library so none are lost if the page closes before they can be sent.
30 minutes
tk_ai
Stores a randomly-generated anonymous visitor ID so Jetpack's Tracks analytics library can link tracking events to the same visitor.
Session in wp-admin; up to 5 years on the frontend
Toggle Microsoft ClarityMicrosoft Clarity
Clarity is a web analytics service that tracks and reports website traffic.
Service URL: clarity.microsoft.com (opens in a new window)
Name
Description
Duration
CLID
Identifies the first-time Clarity saw this user on any site using Clarity.
12 months
ANONCHK
Indicates whether MUID is transferred to ANID, a cookie used for advertising. Clarity doesn't use ANID and so this is always set to 0.
Session
_clck
Persists the Clarity User ID and preferences, unique to that site is attributed to the same user ID.
12 months
_clsk
Connects multiple page views by a user into a single Clarity session recording.
12 months
Toggle Parse.lyParse.ly
Parse.ly is a content analytics platform that helps publishers optimize audience engagement and content performance.
Name
Description
Duration
cookies.js_dtest
This cookie determines whether the browser accepts cookies.
session
_parsely_session
JSON document storing information identifying a browsing session according to Parsely’s proprietary definition
30 minutes
_parsely_visitor
JSON document uniquely identifying a browser and counting its sessions
13 months
Toggle SalespanelSalespanel
Salespanel is a B2B marketing and sales software that identifies, tracks, and qualifies website visitors and leads in real-time using first-party data. It helps businesses monitor customer journeys, score leads based on behavior, and syncs this data with CRMs (like Pipedrive or HubSpot) to improve conversion rates.
Service URL: salespanel.io (opens in a new window)
Name
Description
Duration
track_uid
Identify and tracking a lead
12 moths
Toggle MarketingMarketing
Marketing cookies are used to follow visitors to websites. The intention is to show ads that are relevant and engaging to the individual user.
Toggle Bing / MicrosoftBing / Microsoft
Bing, powered by Microsoft, is a search engine providing web, image, video, and map search capabilities.
Name
Description
Duration
MR
Used to collect information for analytics purposes.
6 months
ANONCHK
Used to store session ID for a users session to ensure that clicks from adverts on the Bing search engine are verified for reporting purposes and for personalisation
10 minutes
SM
Used by Microsoft in synchronizing the MUID across multiple Microsoft domains to track users for advertising.
session
MUID
Identifies unique web browsers visiting Microsoft sites. These cookies are used for advertising, site analytics, and other operational purposes.
1 year
Toggle DoubleClick/Google MarketingDoubleClick/Google Marketing
A comprehensive digital advertising platform for managing campaigns, optimizing performance, and analyzing audience data.
Name
Description
Duration
IDE
This cookie is used for targeting, analyzing and optimisation of ad campaigns in DoubleClick/Google Marketing Suite
2 years
ar_debug
Store and track conversions
Persistent
Toggle LinkedInLinkedIn
LinkedIn is a professional networking platform for job seekers, employers, and industry connections.
Name
Description
Duration
bscookie
Used by LinkedIn to track the use of embedded services.
1 year
AnalyticsSyncHistory
Used to store information about the time a sync with the lms_analytics cookie took place for users in the Designated Countries
30 days
bcookie
Used by LinkedIn to track the use of embedded services.
1 year
li_sugr
Used to make a probabilistic match of a user's identity outside the Designated Countries
90 days
lidc
Used by the social networking service, LinkedIn, for tracking the use of embedded services.
1 day
UserMatchHistory
Used by LinkedIn Ads to synchronize and match user IDs across different ad networks and data providers.
30 days
Toggle LinkedIn InsightLinkedIn Insight
LinkedIn Insight is a web analytics service that tracks and reports website traffic.
Service URL: www.linkedin.com (opens in a new window)
Name
Description
Duration
li_sugr
Used to make a probabilistic match of a user's identity.
90 days
lidc
Used for routing and session management.
24 hours
Toggle LiveIntentLiveIntent
LiveIntent provides a platform for email advertising and identity-driven marketing solutions.
Name
Description
Duration
_lc2_fpi_js
Companion cookie to _lc2_fpi used by JavaScript to facilitate cross-domain ad tracking and user identification.
1 year
_lc2_fpi
First-party tracking cookie usually associated with LiveRamp to identify users across devices for targeted advertising.
1 Year
_li_ss
Sets a unique ID for the visitor, that allows third party advertisers to target the visitor with relevant advertisement. This pairing service is provided by third party advertisement hubs, which facilitates real-time bidding for advertisers.
1 month
lidid
Collects data on visitors' behaviour and interaction - This is used to make advertisement on the website more relevant. The cookie also allows the website to detect any referrals from other websites.
2 years
Toggle Cookie PolicyCookie Policy
You can find more information in our Privacy Policy.
Allow AllDecline All
Accept