Build better products with our product team
There should be a setting in the new launch to be able to track s.products without going to the custom code to build the product string.Kind of like how the old GTM had a checkbox to enable e-commerce tracking and it would just read the dataLayer Enhanced Ecommerce (UA) Developer Guide | Google Tag Manager for Web Tracking | Google Developers
Total Environment Sarjapur Road is an upcoming ultra-premium residential development in Dommasandra, along the rapidly growing Sarjapur Road corridor of East Bangalore. Spread across approximately 22 acres, the project is planned as a low-density luxury community featuring 7 towers with G+32 floors and around 1,052 residences. Designed for discerning homebuyers, the development focuses on spacious layouts, distinctive architecture, landscaped surroundings, and a more private living experience.
The older version of the API, 1.4, allowed us to download a JSON of the processing rules in a suite. Since these are instrumental in transforming data into eVars, Props, and Events, they are an essential part of maintaining the data quality of a suite. The newest version of the API, 2.0, does not currently support accessing the processing rules, and it's been stated on Github that, as of this idea submission, processing rules access is not even on the roadmap. Unless Adobe is going to eliminate these rules (and the eVars and Props that are driven by them), a mature multi-site installation of Adobe Analytics, esp. across mobile and web, relies on a constant overview of processing rules for maintenance, QA, and to aid site and mobile app developers.Please make sure that processing rules are accessible via the APIs, not just in version 2.0, but in all future versions. Leaving 1.4 up is not a complete solution, as Adobe may deprecate it at any point.
A way to bulk unpublish or publish Marketo emails to MSI would be very useful. I see similar ideas over 12 years old, so creating a new idea here. I am trying to clean up MSI folders for our SFDC users. I have over 125 emails that I need to unpublish and i need to do the unpublishing manually, one-by-one. Would be great if Marketo would let me bulk check emails to publish or un-publish.
I have several report builder reports that got out to many stakeholders. Anytime a change is made to one of the reports, it needs to be rescheduled so that the report will send with the changes. Simply going in to edit the schedule of the report and selecting “current workbook” does not actually update the file sent to the latest file with the changes. Because of this, the schedule needs to be set up from scratch again, which can be quite tedious when the recipient list is long and each individual needs to get re-entered because publishing lists are no longer an option.
I am very frustrated by the lack of sharing ability with the Approval Workflows. why is the functionality limited to either a specific person, or the entire company? so either i spend time selecting the exact users for over 400 different workflows. OR i share it with the entire instance and everyone has access to everything in a giant never ending list? We need to be able to share with specific groups and specific teams, Exactly the same way that all the other sharing permissions operate.
I think the new “Assets” Tab now looks much nicer than the classic view.Having said that, I do miss the old icons that showed whether the trigger campaigns were activated versus not. It was also helpful for the batch ones to see which ones are actively scheduled, previously ran, never ran, etc. Food for thought!
While it is currently possible to select multiple assets within the UI, the available filters do not provide an option to view assets located exclusively in archived folders. At present, users can only choose to include archived folders in their search results, which means archived and active assets are returned together.It would be valuable to have the ability to filter for archived folders only.Use CaseDuring instance clean-up and governance activities, teams often need to review assets that have already been archived. Being able to isolate assets within archived folders would make it easier to distinguish them from live, in-use assets, reducing the risk of accidentally unapproving, modifying, or deleting active assets. This functionality would improve efficiency, support better instance management, and help ensure that clean-up efforts are focused only on retired content.
DescriptionImprove Timesheet Behavior for Manually Pinned TasksWhy is this feature important to youCurrently, manually pinned tasks remain on a user's timesheet even after being marked as Completed or Cancelled. This can lead to confusion, as users may continue logging hours on tasks that are no longer active. It also affects data accuracy and time tracking consistency.How would you like the feature to workWe suggest enhancing the timesheet functionality to better handle manually pinned tasks by:Automatically removing pinned tasks from the timesheet once they are marked as Completed or CancelledPreventing time entry on tasks that are no longer active, regardless of manual pinningIntroducing configuration options to restrict manual pinning based on task statusAllowing system administrators to disable the manual pinning feature (Alt+P) for specific user profiles or globallyCurrent BehaviourUsers can manually pin tasks to their timesheet using Alt+P or the pin iconPinned tasks remain visible on the timesheet even after being marked as Completed or CancelledUsers can continue logging hours on these tasksThe existing setting “Pre-populate timesheets with completed or cancelled tasks” does not affect manually pinned tasks
Description - It would be helpful to have an On Hold (ONH) status for Tasks like there are for Projects and Requests. Why is this feature important to you - Sometimes tasks need to be put on hold as priorities change, etc. We'd like to indicate the true status because it's not New, In Progress, or Complete.How would you like the feature to work - Choose On Hold from the Status dropdown menu and remove it from being factored into the Project Condition. Current Behaviour - Tasks have three options New, In Progress, or Complete. We created a custom On Hold status, but it affects the Project Condition, so we adjust the dates repeatedly until the task is re-engaged and changed to In Progress or Cancelled (another custom status created.) For Cancelled Tasks, we can delete the task but it's useful to show the task was considered for the project. We remove dates and planned duration/hours for it so it will not impact the Project Condition. We don't want to remove them from On Hold tasks so the stakeholders know the effort needed should it be decided to move forward.
Attached/below. Keen to hear counterpoints and other considerations for use.
CNIL has created a need to add the logic to send an email with disabled tracking for France leads. The same would be true for Italy soon, but this also means that we are modifying all “Send Email” steps with a choice, or replacing it with a requested/executable campaign. If this conditional setting and the ability to modify it is inbuilt into the email, that would help enable/disable tracking in a dynamic manner for the emails which are already in use. The parameters may extend to beyond tracking pixels as compliance landscape evolves and the settings could be beyond pixel tracking overtime.
From Gut Feeling to Grade Point: How AJO Measures Service QualityHow we grade every service behind Adobe Journey Optimizer — and what happens when a grade slips. When you're running customer journeys that depend on Adobe Journey Optimizer, you're trusting that the platform underneath is holding up its end—every trigger fires, every send lands, every integration behaves the way it should. That trust is something we take seriously, and we've built a system to hold ourselves accountable to it in a very concrete way: the Service Scorecard.The Service Scorecard gives every service that powers AJO an automated grade, refreshed twice a day, across four dimensions that together define what “healthy” means: how well we respond when incidents happen, how thoroughly the code is tested before it ships, how much reliability margin we're maintaining against our own commitments, and how quickly we act on reported issues.This is part of a wider effort across Adobe Experience Platform to apply one consistent quality bar everywhere—and AJO has seen some of the strongest gains in reliability and responsiveness as a result. Why These Four DimensionsEach dimension maps to a distinct point in a service's operational lifecycle:Before code ships — automated test coverage (Code Quality) While it's running in production — reliability against SLO commitments (Reliability Against Our Commitments) When something breaks — root-cause closure and corrective action completion (Incident Follow-Through) When a customer reports an issue — resolution time against SLA (Speed of Resolution) Four Dimensions, One GradeRather than judging a service by a single metric, the Scorecard looks at the full picture. Each service earns a letter grade, A through F, based on:🧪 Code QualityThis dimension measures automated test coverage—the percentage of a service's codebase exercised by automated tests. Coverage is tracked per service and rolled into the score as a direct percentage. Higher coverage is a leading indicator of fewer regressions across releases.⚡ Reliability Against Our CommitmentsEvery service has a reliability target—a service-level objective (SLO)—that it's expected to meet, and this dimension tracks the error budget remaining against that target. The calculation pulls reliability data across AJO's internal service dependencies, so if a service depends on another AJO service that's degraded, that impact is reflected in this score—even though the dependency relationship itself isn't shown directly. This dimension is scoped to dependencies within AJO; it doesn't extend into upstream platforms like Adobe Experience Platform or Real-Time CDP.🚨 Incident Follow-ThroughThis dimension is measured against committed SLAs for incident resolution and root-cause closure. It tracks whether root-cause analysis and every corrective action tied to a CSO (Critical Service Outage) are fully completed—not just whether the incident was mitigated. A CSO isn't marked closed in this score until every associated action item is actually done.🐛 Speed of ResolutionThis dimension tracks how quickly reported issues get resolved, weighted by severity against SLA targets. That includes issues reported through Adobe Support, as well as issues caught internally before they ever reach a customer—including bugs caught through our automated Customer Use Case (CUC) testing, which runs real customer scenarios end-to-end against every release candidate. A critical, widely-felt issue is held to a tighter SLA than a low-severity edge case, and that weighting is built directly into the score.We covered CUC testing in detail in an earlier post: Catching Bugs Before Customers Do. A service's overall grade blends the dimensions that apply to it:A Excellent — low risk, high discipline B Good — healthy, minor gaps C Acceptable — attention needed D Poor — active remediation underway F Critical — immediate escalation Every service on AJO is held to a bar of B or better across all four dimensions. Why We Built It This WayA grade only matters if it's trustworthy, so we designed the Scorecard around a few principles:The same yardstick, every time. Every service is measured identically, so a grade means the same thing no matter which team or capability you're looking at. Updated twice a day, not quarterly. Grades roll forward continuously, so what you're looking at reflects current reality, not a stale snapshot. A named owner for every score. Each service has someone directly accountable for its grade, with clear visibility into exactly what's driving it up or down. Zoomed in or zoomed out. The same data supports a leadership-level view of overall platform health and a team-level view of a single service—so everyone from an engineer to a director is looking at the same underlying truth. A FAIR QUESTION We know the obvious one: doesn't self-grading just let a team grade itself easy? Every score comes from the same systems—incident tickets, test coverage, reliability dashboards, support tickets—used organization-wide, not something a team curates. And the bar itself is fixed platform-wide; no team can lower it to flatter its own grade. How a Grade Gets MadeThis is the core of the Scorecard: a single algorithm that calculates each of the four dimension scores for every service, independently, across every production region that service runs in—using the same formula and the same thresholds everywhere. Standardization is what makes an A in one region comparable to an A in another, and what makes a director's platform-wide view and an engineer's single-service view consistent with each other.The Service Registry is the backbone this rolls up from. It's the source of truth for which services exist, who owns each one, which capability each service belongs to, and which regions it runs in. Every rollup—service to capability, capability to platform—is driven by the Service Registry's ownership and grouping structure, not by any team's own reporting.Each dimension draws on its own signal: Support & Incident Tickets for Incident Follow-Through, Automated Test Coverage for Code Quality, Support tickets plus automated Customer Use Case testing for Speed of Resolution, and Reliability Monitoring for Reliability Against Our Commitments. Those four scores blend into one A–F grade per service, calculated per region and then rolled up—using the Service Registry's structure—into an overall picture of platform health. Four per-region signals blend into one grade; the Service Registry drives every rollup from service to capability to platform. When a Score Slips, Deployments WaitA grade isn't just for visibility—it drives real action. When a service's grade falls below our bar, it becomes a candidate for what we call quarantine. Leadership reviews the full picture—score, incident history, team capacity, business impact—and services selected for quarantine enter a focused remediation period: production changes pause, including hotfixes, unless leadership explicitly signs off on an exception, while the team's full attention shifts to a concrete set of fixes.Getting out of quarantine takes more than a single number recovering. A service has to reach an overall B grade—and get sign-off from engineering leadership that the underlying risk is genuinely resolved, not just papered over. To be clear : Quarantine doesn't mean a service stops running—your existing journeys and campaigns keep operating. It means that team's roadmap pauses so they can focus entirely on the fix. We take this stance deliberately. A low grade on any of the four dimensions is a signal that a customer, somewhere, is already feeling the effects—whether that's a slower resolution time, a reliability gap, or an incident that hasn't been fully closed out. Shipping new capabilities on top of that isn't a trade-off we're willing to make.This also puts real ownership in the hands of the engineers closest to the work. Rather than quality being managed from a distance, the teams who know a service best are the ones empowered—and expected—to fix it. What This Means Going ForwardThis system is built to catch and resolve issues before they reach you—minimizing customer impact is the goal behind every one of these four dimensions, from root-cause closure to error budget tracking to resolution SLAs. It gives us a continuous, standardized way to hold every service to the same bar, across every region, and act before a quality gap turns into a customer-facing problem.That's what lets your journeys, campaigns, and customer experiences run the way you'd expect them to, day in and day out. COMING NEXT IN THIS SERIES How we're using AI to onboard every AJO service onto a standardized set of service-level objectives—turning a process that used to require deep manual expertise into something fast, consistent, and automatic. Stay tuned. Authors: Shivam Chamoli, Kevin Cabral, and Jigar Shah
Meta data creation is THE key step when feeding new assets into a DAM. Especially when uploading multiple assets, the creation of meaningful titles, descriptions and tags takes a long time or needs to be done with an excel sheet. An AI agent/tool that helps creates this data by reading/viewing the file and it’s content or what an image shows, would be extremely helpful.The agent should ideally also be able to do other things as well, e.g. translate the description and enter it into a specified field (e.g. translating the EN description to FR and adding it into the “French description” field).The Bulk Rename feature in Assets View already works pretty good, but it’s only for the actual file names, not for titles. This is like a mini version of what I’m imagining. Other DAMs already have this, if required, I can provide an example.The AI generated titles and descriptions are well noted, alas, there is no easy way to copy them to the actual title field with just a click or to see a suggestion when entering meta data.
A new feature that would be great to have is the ability to test marketing channel rules as you’re creating/saving them. Similar to what we have for classifications, where you can put in a test string and it will show how that string would be classified. It would be great to have this with marketing channels. How it should work:There should be an option to run a test where you can manually put in a URL, referrer, and other components (based on what components you’ve used to set up your rules). Either have it show up with all of the fields you’ve used and the option to populate them/leave them blank, or have dropdowns where you can select which fields you want to enter info for.Then have it run what you’ve entered against all of your rules and tell you which marketing channel it would get classified into. Why it’s important:Right now when making marketing channel processing rules, there isn’t currently a way to test them. It can be hard to mentally go through all of the rules and figure out how a hit would get classified, especially if you have a lot of rules. The value of being able to test specific types of hits can let users know if their rules are working correctly or not. Especially for Adobe Analytics, where retroactive changes are not possible, this could save data from getting misclassified after rules are set up.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.