Degree, PageRank, Betweenness, Eigenvector-Like Centrality Concepts and Business Interpretation

Learning outcomes

1. AtlasMart problem: “important product” is not one mathematical question

AtlasMart merchandising asks for “the most important products” in a product-to-product interaction network. That sentence is underspecified. A product with many direct connections is different from one pointed to by already-influential products; a bridge between otherwise separate product groups is different again. GDS centrality algorithms are structural measurements over a chosen projection, not universal business-value scores.

The mechanism-first rule is: state the decision question, define the projected edge semantics, then choose the centrality family. If the projection says “customers often viewed these products in the same session,” a centrality score is evidence about that interaction topology. It does not prove margin, causal influence, future demand, or merchandising quality.

2. Four centrality questions, four mechanisms

“Eigenvector-like” is useful language when explaining the family, but GDS now exposes a concrete production-quality gds.eigenvector.* algorithm. PageRank is related but adds jump/damping behavior, so the two should not be treated as aliases.

3. Build a hand-checkable product graph

The fixture below creates six synthetic products and seven RELATED_TO edges. The edge is explicitly an analytics-only “co-interest” relation derived for this lesson, not an order-line fact. strength means non-negative interaction strength; cost is not used by centrality here.

MATCH (n) WHERE n.chapter24 = true DETACH DELETE n;
UNWIND [
  ['CH24-P-A','Camera Hub'], ['CH24-P-B','Lens Basic'],
  ['CH24-P-C','Tripod'], ['CH24-P-D','Creator Kit'],
  ['CH24-P-E','Light'], ['CH24-P-F','Mic']
] AS row
MERGE (p:Product:CH24CentralityProduct {productId: row[0]})
SET p.name = row[1], p.chapter24 = true;

MATCH (a:Product {productId:'CH24-P-A'}), (b:Product {productId:'CH24-P-B'}),
      (c:Product {productId:'CH24-P-C'}), (d:Product {productId:'CH24-P-D'}),
      (e:Product {productId:'CH24-P-E'}), (f:Product {productId:'CH24-P-F'})
CREATE (a)-[:RELATED_TO {strength:4.0}]->(b),
       (a)-[:RELATED_TO {strength:3.0}]->(c),
       (b)-[:RELATED_TO {strength:2.0}]->(d),
       (c)-[:RELATED_TO {strength:2.0}]->(d),
       (d)-[:RELATED_TO {strength:3.0}]->(e),
       (d)-[:RELATED_TO {strength:3.0}]->(f),
       (e)-[:RELATED_TO {strength:1.0}]->(f);

MATCH (p:Product) WHERE p.chapter24 = true
RETURN p.productId, p.name ORDER BY p.productId;

Deterministic invariant: there are six Chapter-24 Product nodes and seven Chapter-24 RELATED_TO relationships. That is fixture evidence, not a measured algorithm result.

4. Project only what the question needs, then estimate

CALL gds.graph.project(
  'atlas-ch24-centrality',
  'CH24CentralityProduct',
  {RELATED_TO: {properties: ['strength']}}
)
YIELD graphName, nodeCount, relationshipCount;

CALL gds.pageRank.stream.estimate('atlas-ch24-centrality', {concurrency: 2})
YIELD nodeCount, relationshipCount, bytesMin, bytesMax, requiredMemory
RETURN *;

CALL gds.betweenness.stream.estimate('atlas-ch24-centrality', {concurrency: 2})
YIELD nodeCount, relationshipCount, bytesMin, bytesMax, requiredMemory
RETURN *;

5. Run Degree first because it is manually falsifiable

// Local direct-connectivity baseline.
CALL gds.degree.stream('atlas-ch24-centrality')
YIELD nodeId, score
RETURN gds.util.asNode(nodeId).productId AS productId, score
ORDER BY score DESC, productId;

// Transitive influence with explicit configuration.
CALL gds.pageRank.stream('atlas-ch24-centrality', {
  maxIterations: 20,
  dampingFactor: 0.85,
  concurrency: 2
}) YIELD nodeId, score
RETURN gds.util.asNode(nodeId).productId AS productId, score
ORDER BY score DESC, productId;

// Exact on this tiny graph because samplingSize is omitted (defaults to node count).
CALL gds.betweenness.stream('atlas-ch24-centrality', {concurrency: 2})
YIELD nodeId, score
RETURN gds.util.asNode(nodeId).productId AS productId, score
ORDER BY score DESC, productId;

CALL gds.eigenvector.stream('atlas-ch24-centrality', {
  maxIterations: 20,
  tolerance: 0.000001,
  concurrency: 2
}) YIELD nodeId, score
RETURN gds.util.asNode(nodeId).productId AS productId, score
ORDER BY score DESC, productId;

Manual Degree baseline: with NATURAL orientation, A has two outgoing RELATED_TO edges, D has two, B/C/E have one, and F has zero. If your Degree result does not reflect the orientation/configuration you intended, investigate the projection before interpreting any more sophisticated score.

6. Weights are semantics, not a free “accuracy” switch

For PageRank, relationshipWeightProperty:'strength' changes how a node distributes its score across outgoing relationships. For Betweenness, a weight is interpreted as shortest-path cost; a large “strength” therefore has the opposite direction from a typical distance/cost interpretation. Reusing strength as a path cost would be semantically wrong even if the procedure accepts the property.

7. Deliberately wrong: choose PageRank because everyone has heard of it

The wrong approach is to run PageRank, sort descending, and call the top product “most valuable.” The concrete defect is a semantic mismatch: PageRank measures graph influence under its score-propagation assumptions, while “valuable” could mean contribution margin, conversion lift, strategic dependency, or customer retention.

The repair is to write an interpretation contract: projection source, edge meaning, direction, weighting, algorithm/configuration, refresh timestamp, and the decision for which the score is only one input. Verify against a simple baseline (Degree), known fixtures, and downstream business evidence rather than renaming a structural score.

Production judgment and bridge

Next, the question changes from “which node is structurally central?” to “which nodes form a structurally dense group?” That requires community-detection assumptions and stability checks rather than centrality ranks.

Summary and next step

Degree, PageRank, Betweenness, Eigenvector-Like Centrality Concepts and Business Interpretation is useful only when its assumptions and observed evidence stay attached to the decision. The examples above establish a reproducible mechanism and boundary; they do not turn one lab result into a universal production rule.

Next, continue to Louvain/Leiden/Label Propagation and Community Detection: Resolution, Stability, and Validation. Carry forward the verified assumptions, fixture state, version/edition boundaries, and measurements from this lesson instead of treating the next topic as an isolated recipe.

Authoritative references

• GDS Manual v2026.07 — Current Graph Data Science manual and release baseline.
• GDS supported Neo4j versions — Compatibility matrix mapping Neo4j 2026.07 to GDS 2026.07.
• GDS editions — Community includes all algorithms but caps concurrency at four CPU cores and the model catalog at three models; Enterprise adds operational capabilities.
• Algorithm syntax and execution modes — stream/stats/mutate/write/estimate semantics and common algorithm configuration.
• Memory estimation — Estimate memory before allocating algorithm working state.
• Centrality algorithms — Current centrality family and quality tiers.
• Degree Centrality — Degree semantics and weighted/directed behavior.
• PageRank — PageRank iteration, damping, weights, and execution modes.
• Betweenness Centrality — Exact/sampled betweenness, samplingSize/samplingSeed, memory and concurrency tradeoffs.
• Eigenvector Centrality — Transitive influence and power-iteration semantics.
• Louvain — Modularity, levels, tolerance, seeding and execution modes.
• Leiden — Community detection with gamma, theta, randomSeed and connectivity refinement.
• Label Propagation — Fast topology-driven community detection, optional weights and seeds.
• Node Similarity — Structural neighborhood similarity with Jaccard, Overlap, or Cosine.
• K-Nearest Neighbors — Property-based approximate KNN and supported metrics.
• Path finding algorithms — Current shortest path, traversal, spanning, and flow families.
• Dijkstra Source-Target — Positive-cost shortest path semantics; sourceNode/targetNodes current syntax.
• Breadth First Search — Reachability traversal, targets, maxDepth, and stream/mutate modes.
• Graph algorithm operations reference — Current procedure/function names including spanningTree and similarity functions.
• Neo4j current versions — Current Neo4j database release and 5.26 LTS line.