Is it Embedded Analytics, or Just a Report in an Iframe?

Iframes vs embedded analytics

The analytics user needs access to data within the core business application’s workflow. Anything that causes the user to leave that application or portal to open another takes analytics away from the point of decision. That makes analytics more difficult, which won’t help with adoption. Users work best with embedded analytics.

True Embedded Analytics vs. Iframes and Embedded Output

Vendors who cling to iframes that separate report and dashboard designers don’t meet our standards for embedded self-service analytics.

Many vendors still claim using iframes meets the definition of embedded analytics. An iframe is displaying a second webpage in one window of your browser. Without a lot of extra code it won’t be responsive, making it difficult to read on mobile devices. It only puts a piece of the analytics solution close to the end user’s daily workflow with the application.

Other vendors only embed pieces of the analytics solution. They may include the output of their analytics solution. Report and dashboard design remains outside of the business application, usually requiring a separate application. This may require technical expertise to use and at least a power user’s abilities. But they often need IT staff for report creation.

Software companies and enterprises want end users engaged in the analytics solution to make the best business decisions for their organizations.

Let’s look at these problems one by one.

Iframes Re-render Web Pages from the BI Vendor

A solution that uses iframes is not a cohesive part of the application’s UX. It’s not fully integrated. Iframes need duplicate CSS and JavaScript to integrate with the application. That’s two sets of code just to render the iframe itself, plus the application’s code. Complexity breeds maintenance issues.

The WC3 reports the deprecation of many iframe attributes in HTML5, which they describe here. So you’ll need to use CSS to style the iframe, even to include scrollbars.

Iframes Don’t Get Your Application to Market Quicker

Despite claims to the contrary, iframes won’t get analytics integrated any faster than embedding. It takes about the same time.

The steps remain the same. To drop analytics in through iframes, at minimum it requires going through an install of the target application. The software product team will need to white label analytics using CSS, Html and JavaScript.

Iframes Don’t Enable Users to Tag a Position in a Report

End users always have those “go to” reports and dashboards which they depend on to get answers about the business. But if they need to go through many menus and make the same settings to return to a report they used earlier in the day, they lose opportunities for insight. Users need these bookmarks and tags to serve as their menus to analysis.

Iframes Complicate Debugging

In a blog on “The iFrame is Evil!,” Robert Blackburn said that “The more moving parts there are to a system, the harder it is to diagnose a problem.” Debugging a problem when you need to identify where it occurs gets tougher with iframes. The software company’s application has plenty of things happening on the web page where the iframe gets inserted. Now the BI vendor adds complications that include the CSS and JavaScript necessary to attempt responsiveness and white labeling. Copying the code within the iframe to test it outside of the application does not replicate the real world problem. And how often do software developers encounter problems when two disparate code bases (see below) come together?

Iframes Introduce Disparate Codebases

Iframed applications typically have very little open code, with lots of their code base compiled into their front end. For a vendor whose codebase lacks open and extensible front end code elements, almost by design customization is not possible. Kevin Hoffman wrote that having multiple codebases “makes it nearly impossible to automate the build and deploy phases of your application’s life cycle.”

Iframes Slow Down Page Loading

Any communication between the application’s main page and the iframe is difficult. The browser makes multiple calls on the server. In his blog, developer Krasimir Tsonev said using a postMessage API or passing GET parameters to the iframe’s page is not as straightforward as the JavaScript-only approach.

Iframes Are Not Responsive

The software product team always has to provide the width and height of the iframe, which negates responsiveness. Any workarounds still have an issue with size, especially on a mobile device with its orientation changes.

The team working on the front end will need to write more JavaScript and CSS to fit the analytics solution as they attempt responsiveness and matching styles to the application. They’ll write div tags to actually render the iframe inside the application’s code base.

Iframes Introduce a Second Security Structure

Many iframe proponents say that using them enhances security because it doesn’t expose your application’s codebase. But vulnerabilities of iframes within your application pages aside, their analytics platform already has full access to your data. So what they’ve done is increase the potential vulnerabilities to your data. Compliance requirements that stem from HIPAA and other government regulations and privacy laws make keeping data secure essential. Your customers don’t want their data leaked from a competitive standpoint either.

The iframe method requires that you and your BI vendor establish and maintain a second set of security measures.

Izenda’s Purpose-Built Platform Simplifies Integration

Izenda makes the embedding process simpler with our modern 3-tier architecture. The software product team places our open and extensible front end codebase alongside their product’s front end. Software product teams can customize at the points where it’s needed with the Izenda front end. The exposed REST API endpoints with Izenda go far and above what any other vendor can compare to. We built ourselves from scratch with embedding in mind.

The software product team write a little bit of CSS to white label Izenda’s content. And with a single line of JavaScript and a line of HTML to render inside of the application’s page, Izenda’s solution already is responsive by design. That’s less work and less duplication of effort.

The initial integration of Izenda brings the software application to at least an MVP (minimally viable product) out of the box, so software companies and software product teams inside of enterprises can implement and go live with analytics quickly. As the company moves past an MVP and gains more user feedback, they can customize your application. If the company wants to crack into reporting UIs, they can go deeper with the customization.

Leave a Reply