Frequently Asked Questions

Apollo Features

Yes! We provide almost 1,000 included business requirements, but you can add as many as you want. The included business requirements represent the business questions we have seen asked repeatedly over the past twenty years.

We fully expect that you will want to add business requirements that are unique to your business. You can add business requirements one at a time, or we have a bulk upload process. You do have to provide some additional information when adding a new business requirement so that it works like all other business requirements. This includes the solution design, information related to the data layer, tagging specs, and the tag management configuration.

We have documentation and training on how to do this or you can work with Search Discovery or one of the Apollo partners to help you import custom business requirements.

No! While Apollo is a no-brainer for new digital analytics implementations, it was built to support existing implementations. We assume that most organizations already have a digital analytics implementation with historical data that they want to preserve.

We built a “Map Existing Implementation” tool that allows you to migrate your current implementation to Apollo and then make it better with our additional business requirements and other features. Importing your current analytics implementation can be done in a few hours, and after the import, you can instantly see a list of the business requirements/questions that your implementation can provide to stakeholders.

While many of our business requirements are industry agnostic, we have filters for the following industry verticals: Automotive, B2B, Consumer Products/Manufacturing, Education, Finance, Healthcare, Media, Non-profit/Political, Retail, Travel.

The data quality assurance capabilities in Apollo are powerful, but in many ways different from those offered by traditional data quality tools like ObservePoint or QA2L. Apollo does not currently spider your website and verify that tags haven’t been dropped or allow you to create automated journey tests (though this functionality may be added soon).

Apollo’s data quality features are very focused on ensuring that the data being passed to the data layer is adhering to the data layer requirements and that the beacon being sent to the digital analytics vendor is properly formatted. This will help minimize situations in which bad data ends up in your analytics implementation.

Apollo is able to do this since it builds the data layer for you and has complete knowledge of what data and data constraints are required. This means that you don’t have to take additional time to “teach” Apollo about your implementation whenever you make changes. Apollo also provides real-time feedback on potential data quality issues in the browser, in a third-party logging tool (Airbrake), and via email alerts.

Another key differentiator in Apollo that we’re working on is providing the ability to see which business requirements/questions you cannot answer due to data quality issues. This will be something unique to Apollo and the digital analytics industry. Instead of trying to convince executives of the importance of data quality, Apollo can show executives which business questions cannot be answered at any given time due to data quality issues. This helps get everyone on the same page regarding the importance of data quality.

Soon! It is on our roadmap to have Apollo create mobile app SDKs for you based upon the same business requirements and data layer you have for your desktop website.
Yes! Because Apollo configures an event-driven data layer, single-page apps are covered.
No! Apollo only stores metadata about your implementation such as business questions, implementation attributes, etc. No digital analytics data is stored in Apollo. This often alleviates any concerns about Apollo with your information security team.

This is on our roadmap. We would like to be able to create metadata attributes on your behalf, but we require some API enhancements from vendors before we can do this. It is unlikely that we will populate metadata attributes since there are other vendors like Claravine and ObservePoint that offer this capability. We would likely partner with these firms for metadata population.

Not yet! This is a popular request! We have seen organizations with hundreds of duplicate analytics components and we think managing these and avoiding duplicates would be a great addition to an analytics management system. There are some great tools out there for this (like this one) that we may work with in the future.

Apollo Integrations

This is coming soon. As you may know, Google recently made some changes to their product, which forced us to update our Apollo Google Analytics integration. If you want to be notified when Apollo is ready for Google Analytics, please complete this form to be added to the waitlist.

This is on our product roadmap. As described above, our main priorities were to focus on Adobe Launch for Adobe Analytics customers and GTM for Google Analytics customers since those are the predominant digital analytics tools and tag managers. But we have had numerous requests for additional tag management systems. We will add those based upon two factors: 1) the tag management system provides APIs that we can use to programmatically configure the TMS and 2) we have sufficient demand for customers using the tag management system.

Keep in mind that you can still leverage about 80% of Apollo’s functionality even if your tag management system isn’t supported. You would only miss out on the automated setup of your TMS. For this reason, you may want to still consider using Apollo to manage everything except your TMS until your TMS is supported.

Yes! If you are using Apollo to manage a traditional (non-AEP) Adobe Analytics implementation, Apollo can translate it to XDM and send data to the Adobe Edge Network. This includes the auto-creation of the XDM schema and datastream. If you are creating a new Adobe Analytics implementation and want to use the new AEP Web SDK, Apollo supports that as well.
It is our intention to add other version control tools like Jira, Bitbucket, etc. This will be prioritized by client demand. So far, most of the organizations we have worked with leverage GitHub in some capacity, so that is why we began with GitHub integration.

For now, Apollo is not auto-configuring or managing third-party tags. We know many organizations have these third-party tags in their tag management system, so, for now, you can continue to have those tags in your tag management system, but have them not be created or managed by Apollo.

In the [hopefully near] future, we will be adding new global business requirements around the most popular third-party tags, which will allow Apollo to automatically import the extensions needed for those tags and auto-deploy them using the Apollo data layer.

Apollo Partner Program

Yes! We set out to change the way the industry manages its analytics, and we want as many people benefiting from Apollo as possible.

We offer training to agencies/consultancies on the platform and will help support you on your first Apollo implementation. The Apollo product has been built with safeguards to ensure that anything added to Apollo (such as new business requirements) is only seen by that agency and its clients and that none of your competitors (or Search Discovery) can see what you have added.

We have special pricing plans for agencies/consultancies, so if you are interested in learning more, please visit the partner page on the Apollo website and complete the form there.

Apollo Implementation

As you probably know, data layers are complex. There are custom/homegrown data layers, the W3C data layer, event-driven data layers, vendor-specific data layers, etc. By default, Apollo provides you with a best-practice, event-driven data layer. This is based upon where we see the industry and vendors (both Adobe and Google) going. If your organization is using an old, custom, or static data layer, there will be work involved in using Apollo. If you are already using an event-driven data layer, the work to adapt it to Apollo’s data layer or vice versa is very reasonable.

We understand that making changes to your data layer is difficult and time-consuming, but we believe that every organization should keep up with the industry best-practices and Apollo allows you to improve your digital analytics implementation, its management, and your data layer at the same time. Once you are managing your digital analytics implementation using Apollo, you will have a clean implementation and a data layer that will support you for years to come. So even if there is some work involved to do a one-time update, we have found that it is worthwhile and that the time you save over the long run with Apollo will pay great dividends.

In upcoming months, we will be working to make Apollo adapt to any type of data layer to make the transition to a best-practice data layer as easy as possible.

Once you are managing your analytics implementation in Apollo, you shouldn’t have to make very many updates to the administration settings of your digital analytics tool or your tag management system. By managing these elements directly in Apollo, you can be assured that all of the associations between the various implementation components are maintained.

That being said, if you do make changes to variable settings in the administration area, Apollo will only overwrite those that it is managing. For example, if you change the name of an eVar in the administration console, that name will be replaced by the name found in Apollo. But if you have a variable that you haven’t added to Apollo, any changes made to that in the administration console will remain. In addition, just to be safe, Apollo will never remove a variable from the administration area.

When it comes to the tag management system, Apollo will only update data elements and rules that it manages. If you have additional items in your tag management system that are outside of the scope of Apollo, they will remain untouched. But if you do make manual changes to items in your tag management system that are managed by Apollo, they will be overwritten. Apollo can provide an indicator of which elements it is managing so you can see this in your tag management system.

No. Unfortunately, Adobe doesn’t provide APIs for all of the administration console features, which limits our ability to automate those tasks.

Getting Started With Apollo

The Apollo product has a base price of $30,000. This price includes all of the Apollo features and the ongoing ability to add new items to your implementation, having your implementation documentation always be current, and ongoing quality assurance capabilities. If you have a very custom analytics implementation, there may be additional costs associated with adding custom business requirements or adapting Apollo to your current data layer. You can get exact pricing by contacting us via the form on the Apollo website (www.apolloplatform.com/pricing).
No! We have built Apollo so that it builds all of your implementation components, but does not forever tie you to Apollo. You can download your latest solution design resource (SDR), your data layer and your Launch setup is independent of Apollo. Of course, if you stop using Apollo, you will have to go back to the old way of manually managing an implementation with spreadsheets, but technically, you can use Apollo for however long you wish.

For now, if you want to get your hands on Apollo, your best bet is to complete the form on the Apollo website (www.apolloplatform.com).

We offer live training classes for new customers and agency partners. We also have recorded training classes and a full online knowledge base.
We offer in-product chat support during business hours and email support after-hours. We also have dedicated account managers who are available for phone consultations.

Any other questions? Reach out here!