Cumul.io 통합을 통해 단순해진 임베디드 분석

반응형

트위터, LinkedIn, Reddit, Discord에서 SaaS 커뮤니티를 검색하면 많은 커뮤니티에서 공통 테마가 나타나는 것을 볼 수 있습니다. 이 테마는 BI, 분석, 통찰력 등 여러 이름으로 통할 수 있습니다. 우리가 사업을 하고, 데이터를 수집하고, 성공하든 실패하든 그것은 당연합니다. 우리는 이 모든 것을 조사하고, 우리가 가지고 있는 데이터를 어느 정도 이해하고, 조치를 취하기를 원합니다. 이러한 요구로 인해 데이터를 좀 더 쉽게 조사하고자 하는 모든 사용자의 삶을 보다 쉽게 만들어 주는 많은 프로젝트와 도구가 생성되었습니다. 하지만, 인간이 그랬을 때, 인간은 더 많은 것을 원한다. BI 및 분석의 세계에서는 임베딩, 브랜딩, 맞춤형 스타일링 및 액세스 등의 형태로 "더 많은"가 종종 발생합니다. 이는 결국 개발자들에게 더 많은 작업과 더 많은 설명 시간을 의미하게 됩니다. 따라서 자연스럽게 모든 것을 사용할 수 있는 BI 도구가 필요하게 되었습니다.

이러한 대시보드의 구축자 및 유지관리자로서 직면할 수 있는 당면 과제 목록을 작성해 보겠습니다.

• 최종 사용자 또는 뷰어가 자신의 애플리케이션 또는 플랫폼 내에서 대시보드를 사용할 수 있도록 하려는 경우
• 다양한 대시보드 모음("통합")을 관리할 수 있어야 합니다.
• 대시보드 및 데이터 세트 모음에 특정 사용자 권한을 부여하고자 하는 경우
• 사용자가 자신과만 관련된 데이터에 액세스할 수 있는지 확인하려고 합니다.

Cumul.io은 이러한 과제를 해결하는 데 도움이 되는 통합이라는 도구를 제공합니다. 이 기사에서는 통합이 무엇인지, 통합 설정 방법에 대해 설명합니다. 멋진 점은 위의 대부분의 포인트에서 필요한 최소한의 코드가 있으며 대부분의 경우 Cumul.io UI 내에서 설정할 수 있다는 것입니다.

일부 배경 - 통합

 

Cumul.io의 통합은 함께 사용하도록 의도된 대시보드 모음(예: 동일한 애플리케이션에서)을 정의하는 구조이다. 또한 애플리케이션에 대시보드를 내장하는 데 사용됩니다. 다시 말해, 대시보드를 애플리케이션에 내장하기 위해 대시보드가 속한 통합에 대한 액세스 권한을 애플리케이션에 부여합니다. 대시보드를 통합에 연결하고 통합 최종 사용자가 이러한 대시보드 및 사용하는 데이터 세트에 대해 가질 액세스 권한 유형을 관리할 수 있습니다. 대시보드는 여러 통합의 일부일 수 있지만 여러 통합에 대해 서로 다른 액세스 권한을 가질 수 있습니다. 임베딩에 관한 한, 스택의 모양에 관계없이 여러 SDK를 사용하여 간편하게 작업을 수행할 수 있습니다.

Cumul.io 계정이 있고 Cumul.io에 있는 조직의 "소유자"인 경우 통합 탭을 통해 모든 통합을 관리하고 유지할 수 있습니다. Cumul.io 계정의 예를 살펴봅시다. 아래에는 Cumul.io 사용자가 만들었을 수 있는 대시보드를 볼 수 있습니다.

이 사용자가 만든 대시보드는 모두 이러한 대시보드이지만, 모든 대시보드가 동일한 최종 사용자 또는 애플리케이션을 위한 것은 아닐 수 있습니다. 이 Cumul.io 계정의 소유자는 통합(또는 그 이상)을 생성하고 유지 관리합니다. 어떤 모습일지 살펴보겠습니다.

 

따라서 이 Cumul.io 계정의 소유자는 두 개의 별도 애플리케이션을 관리하는 것으로 보입니다.

이제 통합을 만들고 대시보드를 애플리케이션에 내장하는 프로세스가 어떤 모습인지 살펴보겠습니다. 좋은 소식은 앞서 언급한 바와 같이 Cumul.io UI에서 수행해야 할 많은 단계를 수행할 수 있다는 것입니다.

거부권: 이 글의 목적상, 저는 통합 부분에만 초점을 맞춥니다. 대시보드 생성 및 설계와 관련된 모든 작업은 생략하고 미리 만들어진 가상 대시보드 세트로 시작하겠습니다.

앞으로 어떻게 할 것인가:

통합 만들기

 

단순화를 위해 지금은 하나의 통합만 만들어 보겠습니다. 회사를 위해 유지 관리하는 분석 플랫폼이 있다고 가정해 보겠습니다. 최종 사용자에게 제공하고자 하는 대시보드는 마케팅 대시보드, 영업 대시보드 및 잠재 고객 대시보드의 세 가지입니다.

이 계정이 이 특정 프로젝트에 대해 생성했거나 액세스할 수 있는 모든 대시보드 중에서 다음 항목만 사용하고자 한다고 가정해 보겠습니다.

통합을 만들려면 통합 탭으로 이동하여 새 통합을 선택합니다. 나타나는 대화는 다음 단계에 대한 몇 가지 정보를 제공합니다.

 

그런 다음 이 통합에 포함할 대시보드를 선택할 수 있습니다. 또한 통합에 이름을 붙일 수 있습니다. 여기서 "매우 중요한 통합"이라는 이름을 사용하기로 결정했습니다.

선택을 확인하면 각 대시보드에 대해 슬러그를 정의하는 옵션이 제공됩니다(강요 권장). 나중에 대시보드를 애플리케이션에 내장하는 동안 이러한 기능을 사용할 수 있습니다. 나중에 알게 될 슬러그는 프런트 엔드 코드에서 대시보드를 쉽게 참조할 수 있게 해 주며 필요한 경우 대시보드를 쉽게 교체할 수 있게 해 줍니다(프런트 엔드 코드에서 대시보드 ID를 걱정할 필요가 없음).

그런 다음 대시보드에서 사용하는 데이터 세트에 대한 통합의 액세스 권한을 설정할 수 있습니다. 여기서 우리는 이것을 "Can view"로 설정합니다. 액세스 권한과 그에 수반되는 기능에 대한 자세한 내용은 통합에 연결된 데이터셋을 참조하십시오.

 

사이드 노트: Cumul.io에서는 가상 설정에서 사용할 수 있는 멀티 테넌트 액세스를 지원하기 위해 대시보드에서 사용하는 데이터 세트에 매개 변수와 필터를 설정할 수 있습니다. 즉, 분석 플랫폼에 로그인하는 각 사용자는 대시보드에서 개인적으로 액세스할 수 있는 데이터만 볼 수 있습니다. 이 시나리오에서 액세스 권한은 최종 사용자가 회사에서 근무하는 부서에 따라 결정된다고 가정할 수 있습니다. Cumul.io으로 멀티 테넌시를 설정하는 방법에 대한 자세한 내용은 "Cumul.io Dashboards on Auth0" 기사를 참조하십시오. 이 작업은 건너뛰는 대시보드 설계 프로세스 내에서 수행할 수 있으므로 필터의 작업을 보다 쉽게 시각화할 수 있습니다. 여기서는 통합 생성 프로세스에서 이러한 필터를 설정합니다.

Here, we set the filters the datasets might need to have. In this scenario, as we filter based on the users’ departments, we define a `department` parameter and filter based on that:

그리고 짜잔! 설정을 마치면 통합이 성공적으로 작성됩니다. 다음 대화에서는 통합을 내장하기 위한 다음 단계를 안내합니다.

 

이제 통합 탭에서 이 새로운 통합을 볼 수 있습니다. 또한 나중에 대시보드를 내장하는 데 사용될 통합 ID에 빠르게 액세스할 수 있습니다.

좋은 소식이야! 통합을 만든 후에는 언제든지 편집할 수 있습니다. 대시보드를 제거 또는 추가하거나 대시보드의 슬러그 또는 액세스 권한을 변경할 수도 있습니다. 따라서 애플리케이션이 변화하고 발전함에 따라 새로운 통합을 구축하는 것에 대해 걱정할 필요가 없습니다. 통합 편집은 UI에 모두 포함되므로 개발자가 이 모든 것을 다시 설정할 필요가 없습니다. 비기술 사용자는 이동 중에도 이러한 통합을 조정할 수 있습니다.

대시보드 내장

우리가 어디로 가고 싶은지 봅시다. 사용자 지정 앱 내에서 대시보드를 제공하려고 합니다. 사용자가 앱에 로그인하면 앱에 대시보드가 있고 볼 수 있는 데이터가 포함된 대시보드를 볼 수 있습니다. 예를 들어 다음과 같을 수 있습니다.

 

최종 사용자에게 대시보드를 제공하는 방법에 대한 매우 구체적인 비전을 가지고 있는 사람도 있었습니다. 이들은 각각의 대시보드를 한눈에 볼 수 있는 사이드바를 원했다. 그것은 완전히 다른 것일 수도 있었다. 여기서는 호스트 애플리케이션의 모양에 관계없이 이러한 대시보드를 애플리케이션에 내장할 수 있는 방법에 초점을 맞출 것입니다.

Cumul.io에는 공개적으로 사용 가능한 SDK 세트가 포함되어 있습니다. 노드 SDK를 사용할 경우 어떻게 해야 하는지 보여드리겠습니다. 다른 SDK와 사용 방법에 대한 지침을 보려면 개발자 문서를 확인하십시오.

최종 사용자를 위한 SSO 토큰을 생성하기 전에 Cumul.io에서 API 키와 토큰을 만들어야 합니다. Cumul.io 프로필에서 이 작업을 수행할 수 있습니다. 이 API 키와 토큰을 만들어 SSO 인증 요청을 하는 통합에 대한 액세스 권한을 가진 조직 소유자여야 합니다. 이 작업을 마치면 먼저 애플리케이션의 서버 측에서 수행할 Cumul.io 클라이언트를 만들어 보겠습니다.

const Cumulio = require("cumulio");

const client = new Cumulio({
    api_key: '<YOUR API KEY>',
    api_token: '<YOUR API TOKEN>',
});

 

const Cumulio = require("cumulio");

const client = new Cumulio({
    api_key: '<YOUR API KEY>',
    api_token: '<YOUR API TOKEN>',
});

이제 최종 사용자를 위한 SSO 토큰을 만들 수 있습니다. 이 API 호출과 필수 필드에 대한 자세한 내용은 SSO 토큰 생성에 대한 개발자 설명서를 참조하십시오.

let promise = client.create('authorization', {
    integration_id: '<THE INTEGRATION ID>',
    type: 'sso',
    expiry: '24 hours',
    inactivity_interval: '10 minutes',
    username: '< A unique identifier for your end user >',
    name: '< end-user name >',
    email: '< end-user email >',
    suborganization: '< end-user suborganization >',
    role: 'viewer',
    metadata: {}
});

let promise = client.create('authorization', {
    integration_id: '<THE INTEGRATION ID>',
    type: 'sso',
    expiry: '24 hours',
    inactivity_interval: '10 minutes',
    username: '< A unique identifier for your end user >',
    name: '< end-user name >',
    email: '< end-user email >',
    suborganization: '< end-user suborganization >',
    role: 'viewer',
    metadata: {}
});

Here, notice how we have added the optional `metadata` field. This is where you can provide the parameters and values with which you want to filter the dashboards’ datasets on. In the example we’ve been going through we’ve been filtering based on department so we would be adding this to the metadata. Ideally you would get this information from the authentication provider you use. See a detailed explanation on how we’ve done this with Auth0.

 

이 요청은 인증 ID와 토큰을 포함하는 JSON 개체를 반환하며 나중에 클라이언트 측에 대시보드를 내장하기 위한 키/토큰 조합으로 사용됩니다.

여기에 선택적으로 추가할 수 있는 것은 CSS 속성입니다. 이렇게 하면 각 사용자(또는 사용자 그룹)에 대한 사용자 지정 모양과 느낌을 정의할 수 있습니다. 동일한 애플리케이션의 경우, 마케팅 대시보드는 안젤리나 대 브래드에게 다음과 같이 보일 수 있습니다.

우리는 거기서 조금 앞서 나갔다. 최종 사용자를 위한 SSO 토큰을 만들었지만 대시보드는 아직 애플리케이션에 내장하지 않았습니다. 어디 한번 봅시다. 먼저 웹 구성 요소를 설치하고 가져와야 합니다.

 

import '@cumul.io/cumulio-dashboard';

import '@cumul.io/cumulio-dashboard';

구성 요소를 가져온 후 HTML 태그인 것처럼 사용할 수 있습니다. 대시보드는 다음과 같은 위치에 내장됩니다.

<cumulio-dashboard
                     dashboardId="< a dashboard id >"
                     dashboardSlug="< a dashboard slug >"
                     authKey="< SSO key from step 1 >"
                     authToken="< SSO token from step 1 >">
  </cumulio-dashboard>

<cumulio-dashboard
  dashboardId="< a dashboard id >"
  dashboardSlug="< a dashboard slug >"
  authKey="< SSO key from step 1 >"
  authToken="< SSO token from step 1 >">
    </cumulio-dashboard>

 

여기 몇 가지 옵션이 있습니다. 내장할 대시보드의 대시보드 ID를 제공하거나 통합 설정에서 정의한 대시보드 슬러그를 제공할 수 있습니다. 따라서 이 방법을 사용하는 것이 훨씬 더 읽기 쉽습니다. 대시보드를 내장하는 방법에 대한 자세한 내용은 개발자 설명서를 참조하십시오.

이 단계를 수행하는 좋은 방법은 HTML 파일에 대시보드 구성 요소의 골격을 정의하고 애플리케이션의 클라이언트 측에서 나머지 부분을 채우는 것입니다. 물론 유일한 방법은 아니지만 다음과 같은 작업을 수행했습니다.

I’ve added the dashboard component with the ID `dashboard`:

<cumulio-dashboard id="dashboard"></cumulio-dashboard>

<cumulio-dashboard id="dashboard"></cumulio-dashboard>

 

그런 다음 클라이언트 코드에서 다음과 같이 이 구성 요소를 검색했습니다.

const dashboardElement = document.getElementById("dashboard");

const dashboardElement = document.getElementById("dashboard");

Then I request the SSO token from the server side of my application which returns the required key and token to add to the dashboard component. Let’s assume we have a wrapper function `getDashboardAuthorizationToken()` that does this for us and returns the response from the server-side SSO token request. Next, we simply fill in the dashboard component accordingly:

const authorizationToken = await getDashboardAuthorizationToken();
if (authorizationToken.id && authorizationToken.token) {
    dashboardElement.authToken = authorizationToken.token;
    dashboardElement.authKey = authorizationToken.id;
    dashboardElement.dashboardSlug = "marketing|sales|leads";
}

 

const authorizationToken = await getDashboardAuthorizationToken();
if (authorizationToken.id && authorizationToken.token) {
    dashboardElement.authToken = authorizationToken.token;
    dashboardElement.authKey = authorizationToken.id;
    dashboardElement.dashboardSlug = "marketing|sales|leads";
}

Notice how in the previous steps I chose to define slugs for my dashboards that are a part of this integration. This means I can avoid looking up dashboard IDs and adding `dashboardId` as one of my parameters of the `dashboardElement`. Instead I can just provide one of the slugs `marketing`, `sales` or `leads` and I’m done! Of course you would have to set up some sort of selection process to your application to decide where and when you embed which dashboard.

자, 여러분! Cumul.io에 통합 기능을 성공적으로 구축했으며, 몇 줄의 코드를 통해 대시보드를 애플리케이션에 내장할 수 있었습니다 이제 동일한 회사 내에서 또는 별도의 애플리케이션을 위해 여러 애플리케이션을 한 번에 관리해야 하는 시나리오를 상상해 보십시오. 너의 시나리오, 나는 어떻게 만약 너가 어디를 그들은 각자 다른 장소에 가서 그들은 각자 다른 액세스 권한 위치에, 계속 따라 위에 우리는 go.이 있어 대시 많은 수의 여러분이 상상할 수 있을 거야. 어떻게 빨리 통제 불능이 될 수 있는지. 통합을 통해 한 곳에서, 보시는 바와 같이 대부분 Cumul.io UI 내에서 간단하고 깔끔하게 이 모든 것을 관리할 수 있습니다.

우리가 자세히 살펴보지 않은 당신이 여기서 할 수 있는 일이 훨씬 더 많다. 사용자별 사용자 지정 테마 및 CSS 추가와 같은 항목입니다. 또한 대시보드에서 매개 변수와 필터를 설정하는 방법이나 멀티 테넌트 설정을 위해 호스트 응용 프로그램에서 매개 변수와 필터를 사용하는 방법도 검토하지 않았습니다. 아래에서는 이러한 단계에 대한 유용한 자습서 및 설명서에 대한 링크를 찾을 수 있습니다.

• Cumul.io 개발자 문서
• 사용자 지정 CSS 추가를 위한 아카데미 문서
• Auth0이 포함된 Cumul.io 대시보드의 멀티 테넌시
• SSO 토큰 생성 중
• 임베딩