In this page

Getting started with Better Content Archiving for Confluence

This page explains a couple of simple steps you have to complete before you actually start using the app. Don't worry, these are simple, fast (depending on the size of your Confluence site) and you have to do these only once.

What is the Content Event Index?

Better Content Archiving 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.

Initializing 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 functionality that relies 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 visits, 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.

As a second step, the app suggests calculating the initial content quality statistics. After that is completed, your instance is ready for use!

You can learn more about initializing the two parts of the index in the next two sections.

Initializing the Page Update Index

Confluence precisely tracks page updates, all their details are available in the Confluence data model. Therefore, the app can unambiguously build this part of the index. Zero user interaction is required.

Initializing the Page View Index

(since app version 7.4.0)

Confluence does not track page views, however. It means that Better Content Archiving simply cannot know who viewed what page before the app's installation. This isn't a problem for post-installation page views as the app implements its own precise page view tracking mechanism, but this is definitely a problem for pre-installation ones.

To overcome this, the app offers three strategies to intuitively approximate the last view information when getting started with the app. During the actual use of the app, real page views will continuously replace the approximated values.

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 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.

Please 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.

Re-building 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.

Questions?

Ask us any time.