In this page

Get started with Better Content Archiving for Confluence

This page explains the initial steps you have to complete before you actually start using the app. Don't worry, these are simple, fast, and you have to complete them only once after the installation.

Step 1: Initialize the content event index

What is the content event index?

The Better Content Archiving app maintains an index with the last view (who viewed what, when?) and the last update information for each page. The index stores that information in a scalable and searchable way, eliminating expensive page tree traversals and accelerating various features of the app.

How to initialize the content event index?

Although the index does not require any manual care later, you need to initialize (build) it once after the app's installation. Until the index is built, the app features that rely on views and updates will not work. After the index is initialized, it will be automatically maintained in the background with "micro updates" that are triggered by page views, page edits, attachment additions and so.

The initialization must be executed globally by a Confluence administrator:

  1. Login to Confluence as administrator.
  2. Go to Administration → Content Quality.
  3. Click the Build now button and wait until the job completes.

✓ The content event index is ready to help the features which rely on it.

(If interested, you can learn more about the index parts in the next two sections.)

About the page update index

Confluence tracks page updates. This information is readily available in Confluence data.

Therefore, the app can build this part of the index with full precision.

About the page view index

(since app version 7.4.0)

In contrary, Confluence does not track page views! This information is completely missing from Confluence data.

Therefore, the app cannot know who viewed a page before the app's installation! Starting from the installation, the app can track and know page views, but for prior periods, there is no information available.

To have approximate page views when getting started, the app offers three strategies to initialize the last view information of each page (who and when). While using the app, the actual page views will gradually replace the approximate page views, resulting in a perfectly precise page view index.

You can initialize the last view of each page to:

  1. The same as its last update: the user who last updated the page is considered the last viewer of the page. Note that this is not necessarily the user who most recently edited the page content! As explained in the page "update age" section, it also depends on the most recent attachment addition and on the most recent update on the child pages.
  2. Its last updater and a specific date: it simulates that the user who last updated a page viewed that page in the given day at midnight. You can use it either with the current day (default) or any past day.
  3. Do not touch: it does not touch the last view information at all. We don't recommend this at initialization time, see the next section why.

We suggest using the strategies like this:

  • When building the index (initializing that the first time):
    1. The strategy "same as its last update" absolutely makes sense as the initial value.
    2. Or, you may prefer the "last updater and a specific date" strategy with the current day. Compared to the previous, it sets the same date for all pages, making it a crystal-clear starting point.
    3. Or, you may prefer the "last updater and a specific date" strategy with some past day (e.g. "2016-01-01" can be a good choice). This is essentially the same as previous. Tip: don't use a date in the very far past. (For instance, if you select the date 400 days before today and use 365 days as the not-viewed alert interval, all pages will be immediately reported as not-viewed.)
    4. Using "do not touch" is discouraged. Although it allows starting with empty information (i.e. no approximations), it may also lead to the abandoned pages problem.
  • When re-building the index (later):
    1. You most likely want to use the "do not touch" strategy. This is because in normal circumstances the page view information should not be missing for any page at this stage.
    2. If you removed spaces from the blacklist, then you want to add the missing page view information for the pages in the un-blacklisted spaces. In this case, follow the recommendations in the "building the index the first time" point, because that's essentially the same case.

The default selection in the user interface reflects the recommendations above. If you are unsure, just use the defaults.

Note that page view initialization is non-destructive by design. It means that whatever strategy you choose, if there is already a known last view for a page, that will not be overwritten.

When to re-build the content event index?

In some rare cases, you may need to re-build the index:

  1. After you removed spaces from the blacklist (blacklisted spaces are not indexed to save resources).
  2. Or, when you are experiencing troubles with the app features (potentially caused by index inconsistency).

You can re-build the index both globally or for a single space by clicking the Re-build content update index button in the Content Quality Statistics screen.

Step 2: Calculate the content quality statistics for the first time

Next, calculate the initial content quality statistics:

  1. (You are still following the wizard.)
  2. Click the Calculate now button and wait until the job completes.

✓ ️ The initial content quality statistics are calculated.

Done!

Yay, your app is ready for use!

Questions?

Ask us any time.