I run a small AI visibility tracker that I built myself, and last week I found something in my own pipeline that I have not seen anyone talk about.

I ask each question 7 times per platform so I can show a range instead of a single number. One week Perplexity came back much lower than usual for every domain I track. I assumed those brands had actually lost ground.

They had not. Perplexity was rate limiting me. About 30% of my requests were coming back 429, and my code was quietly counting those as "not mentioned" instead of "not measured". So that platform was being scored on 5 runs while the others got 35, and the smaller sample dragged the number down.

The fix was not sending fewer requests. It was spacing them out. The limit turned out to be roughly one request per second per account, and two scans running at the same time were stepping on each other.

Here is why I am posting it. A failed measurement and a real absence look identical once they land in a chart. My tool now prints how many runs failed right under the percentage, because I could not trust my own number until it did.

So if you are evaluating any of these tools, including mine, that is the question I would ask. Not how many platforms, not how many prompts. Ask what happens when a request fails, and whether the report tells you.

Disclosure: the tool is AnswerRadar and it is mine. Not linking it, this is not a pitch.

Just saw the new Meltwater numbers (9.5M AI citations analyzed across 16 B2B categories) and it's making me rethink where I'm spending GEO effort. LinkedIn is apparently the #2 most-cited source behind YouTube now, ahead of company websites. 75% of those citations trace to personal profiles, not Company Pages, and 51% come from accounts under 10k followers.

Curious if anyone here has actually tested this: has shifting effort toward personal LinkedIn posts (structured, numbered, data-heavy, same stuff that ranks well organically) moved the needle on AI citations for a brand, more than the same effort spent on owned-domain content would have?

Trying to figure out if this is worth reallocating real budget toward or if it's still too early/noisy to trust the data at the tactic level.

I’m a freelancer and created a website with AI (Lovable). I also told the AI to set everything up in a way that would make me discoverable when someone searches for me using AI.

I am totally new to SEO, but I have a tech background.

I changed some of the texts on my website again, and the content was no longer consistent everywhere. It bothered me that I constantly had to check which files contained which pieces of text.

So I let an AI create a Single Source of Truth containing my digital professional identity and had the AI create a script that automatically pulls the information only from this file. The file also serves as the basis for resumes.

On my website is not the full JSON file, just the specific data from it on each specific page.

Here is a fictional example. This is not me, this person is entirely fictional. I’m only giving you the example because I think it is extremely useful.

AI can read it very well. It is a JSON file based on Schema org.

So it also improves the machine readability of the website, and it is extremely practical for keeping the website up to date and for creating resumes. But remember I do not write it manually and the website is also updated via script.

You can just use any AI of your choice, give it your data or information and tell it to create a JSON based on Schema org.

Then you tell the AI that creates your website to make a script that pulls all revelant data from this JSON and put it into the specific pages.

I know this file is huge, but I just want to show you that you can use it for a resume, too. You can also link relevant blogs etc.:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://eriklindstrom.dev/#person",
      "name": "Erik Lindström",
      "givenName": "Erik",
      "familyName": "Lindström",
      "url": "https://eriklindstrom.dev/about",
      "jobTitle": "Senior Data Engineer",
      "description": "Senior data engineer working on streaming, lakehouse architectures and data quality. Builds platforms that still make sense once the person who built them has left the room.",
      "email": "hello@eriklindstrom.dev",
      "image": "https://eriklindstrom.dev/portrait.jpg",
      "telephone": "+46 8 555 0187",
      "nationality": {
        "@type": "Country",
        "name": "Sweden"
      },
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Sankt Eriksgatan 44",
        "postalCode": "112 32",
        "addressLocality": "Stockholm",
        "addressCountry": "SE"
      },
      "knowsLanguage": [
        {
          "@type": "Language",
          "name": "Swedish",
          "alternateName": "sv"
        }
      ],
      "knowsAbout": [
        "Data Engineering",
        "Apache Kafka",
        "Apache Flink",
        "Apache Iceberg",
        "Change Data Capture",
        "dbt",
        "Airflow",
        "Snowflake",
        "DuckDB",
        "Python",
        "Go",
        "SQL",
        "Terraform",
        "Kubernetes",
        "Data Contracts",
        "Data Quality",
        "Cost Engineering",
        "GDPR-Compliant Deletion",
        "Dimensional Modeling",
        "Platform Engineering"
      ],
      "sameAs": [
        "https://www.linkedin.com/in/erik-lindstrom/",
        "https://github.com/elindstrom",
        "https://elindstrom.substack.com/",
        "https://mastodon.social/@elindstrom",
        "https://stackoverflow.com/users/4471902/elindstrom"
      ],
      "mainEntityOfPage": {
        "@id": "https://eriklindstrom.dev/#website"
      },
      "hasOccupation": {
        "@type": "Occupation",
        "name": "Senior Data Engineer",
        "occupationalCategory": "15-1243.00 Database Architects",
        "experienceRequirements": {
          "@type": "OccupationalExperienceRequirements",
          "monthsOfExperience": 172
        },
        "skills": "Streaming architectures on Kafka and Flink, lakehouse design on Iceberg and Delta, change data capture from OLTP sources, dbt modelling at four-digit model counts, cost control for cloud warehouses, data contracts and schema evolution, platform operations on Kubernetes",
        "estimatedSalary": {
          "@type": "MonetaryAmountDistribution",
          "name": "Target salary, permanent employment",
          "currency": "SEK",
          "duration": "P1Y",
          "median": 1250000
        }
      },
      "seeks": {
        "@type": "Demand",
        "@id": "https://eriklindstrom.dev/#seeks",
        "name": "Looking for a Staff Data Engineer or Data Platform Lead position",
        "description": "Open to permanent roles from Q4 2026. Prefers ownership of a platform or a product area over maintaining existing pipelines. Remote-first within Sweden and the Nordic region, with limited on-site work.",
        "availabilityStarts": "2026-11-01",
        "businessFunction": "https://purl.org/goodrelations/v1#ProvideService",
        "itemOffered": {
          "@type": "Occupation",
          "name": "Staff Data Engineer",
          "occupationalCategory": "15-1243.00 Database Architects",
          "alternateName": [
            "Data Platform Engineer",
            "Lead Data Engineer",
            "Principal Data Engineer"
          ]
        },
        "eligibleRegion": [
          {
            "@type": "Country",
            "name": "Sweden"
          },
          {
            "@type": "Country",
            "name": "Norway"
          },
          {
            "@type": "Country",
            "name": "Denmark"
          },
          {
            "@type": "Country",
            "name": "Finland"
          },
          {
            "@type": "Place",
            "name": "Nordic region, remote"
          }
        ]
      },
      "alumniOf": [
        {
          "@type": "CollegeOrUniversity",
          "@id": "https://eriklindstrom.dev/#org-kth",
          "name": "KTH Royal Institute of Technology",
          "description": "M.Sc. Computer Science, focus on distributed systems. Thesis on the consistency guarantees of log-based replication."
        }
      ],
      "hasCredential": [
        {
          "@type": "EducationalOccupationalCredential",
          "name": "M.Sc. Computer Science",
          "credentialCategory": "degree",
          "educationalLevel": "Master",
          "dateCreated": "2013-09",
          "recognizedBy": {
            "@id": "https://eriklindstrom.dev/#org-kth"
          }
        },
        {
          "@type": "EducationalOccupationalCredential",
          "name": "Certified Kubernetes Application Developer (CKAD)",
          "credentialCategory": "certificate",
          "dateCreated": "2021-05"
        }
      ],
      "award": [
        "Internal engineering award at Nordmark Analytics AB, 2023, for the Iceberg migration without downtime",
        "Community award at the Nordic Data Engineering Conference, 2024, for the open-source project backfill-guard"
      ],
      "worksFor": {
        "@id": "https://eriklindstrom.dev/#org-nordicshield"
      },
      "affiliation": [
        {
          "@type": "Role",
          "roleName": "Senior Data Engineer and Tech Lead, Data Platform",
          "startDate": "2024-06",
          "description": "Owns the claims data platform of a Nordic insurance group: change data capture from 14 policy systems, audit-proof historisation and a deletion process that carries GDPR requests verifiably through every layer.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-nordicshield"
          }
        },
        {
          "@type": "Role",
          "roleName": "Staff Data Engineer",
          "startDate": "2022-09",
          "endDate": "2024-05",
          "description": "Migrated a grown Redshift warehouse to an Iceberg lakehouse in production, cutting warehouse cost by 38 percent while shortening load times.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-nordmark"
          }
        },
        {
          "@type": "Role",
          "roleName": "Lead Data Engineer",
          "startDate": "2020-02",
          "endDate": "2022-08",
          "description": "Built a carsharing company's data platform from scratch, including data contracts between product teams and analytics and a self-service model for business departments.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-fjall"
          }
        },
        {
          "@type": "Role",
          "roleName": "Senior Data Engineer",
          "startDate": "2017-07",
          "endDate": "2020-01",
          "description": "Real-time processing of telematics data from around 9,000 vehicles, from Kafka ingestion to arrival-time predictions inside the dispatching system.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-nordicfreight"
          }
        },
        {
          "@type": "Role",
          "roleName": "Data Warehouse Engineer",
          "startDate": "2014-04",
          "endDate": "2017-06",
          "description": "Regulatory reporting and risk reporting at a regional bank, including the move from nightly Oracle batches to incremental processing.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-sveabank"
          }
        },
        {
          "@type": "Role",
          "roleName": "Working Student and Junior BI Developer",
          "startDate": "2011-10",
          "endDate": "2014-03",
          "description": "First contact with production data pipelines: SSIS packages, sales reporting and an instructive collection of Excel exports.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-skandiaretail"
          }
        }
      ],
      "subjectOf": [
        {
          "@id": "https://github.com/elindstrom/backfill-guard"
        },
        {
          "@id": "https://github.com/elindstrom/pg2iceberg"
        },
        {
          "@id": "https://github.com/elindstrom/dbt-costlens"
        },
        {
          "@id": "https://github.com/elindstrom/skewfinder"
        }
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://eriklindstrom.dev/#website",
      "url": "https://eriklindstrom.dev/",
      "name": "Erik Lindström – Senior Data Engineer",
      "description": "Pipelines that hold. Platforms you can understand. Costs somebody actually knows.",
      "inLanguage": "en-US",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "publisher": {
        "@id": "https://eriklindstrom.dev/#person"
      }
    },
    {
      "@type": "Blog",
      "@id": "https://elindstrom.substack.com/#blog",
      "url": "https://elindstrom.substack.com/",
      "name": "Late Arriving Facts",
      "description": "Notes on data modelling, streaming and the cost of convenience. Roughly twice a month.",
      "inLanguage": "en-US",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      }
    },
    {
      "@type": "SoftwareSourceCode",
      "@id": "https://github.com/elindstrom/backfill-guard",
      "name": "backfill-guard",
      "codeRepository": "https://github.com/elindstrom/backfill-guard",
      "programmingLanguage": "Python",
      "license": "https://spdx.org/licenses/Apache-2.0.html",
      "dateCreated": "2021-03-14",
      "dateModified": "2026-07-28",
      "description": "A guard rail for Airflow and Dagster backfills. Checks before writing whether a partition window has already been materialised, enforces watermarks and aborts duplicate writes instead of deduplicating them afterwards. Written after a backfill doubled three months of revenue figures.",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "keywords": [
        "airflow",
        "dagster",
        "idempotency",
        "backfill",
        "data-quality"
      ]
    },
    {
      "@type": "SoftwareSourceCode",
      "@id": "https://github.com/elindstrom/pg2iceberg",
      "name": "pg2iceberg",
      "codeRepository": "https://github.com/elindstrom/pg2iceberg",
      "programmingLanguage": "Go",
      "license": "https://spdx.org/licenses/MIT.html",
      "dateCreated": "2022-11-02",
      "dateModified": "2026-08-05",
      "description": "A CDC connector that writes PostgreSQL logical replication straight into Apache Iceberg tables, with exactly-once commits through Iceberg snapshots and automatic schema evolution for additive changes. No Kafka layer required in between.",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "keywords": [
        "cdc",
        "postgresql",
        "iceberg",
        "lakehouse",
        "golang"
      ]
    },
    {
      "@type": "SoftwareSourceCode",
      "@id": "https://github.com/elindstrom/dbt-costlens",
      "name": "dbt-costlens",
      "codeRepository": "https://github.com/elindstrom/dbt-costlens",
      "programmingLanguage": "Python",
      "license": "https://spdx.org/licenses/Apache-2.0.html",
      "dateCreated": "2023-06-19",
      "dateModified": "2026-06-11",
      "description": "Attributes Snowflake and BigQuery query cost to individual dbt models and surfaces it in the pull request. Configurable budgets per model folder, warnings when cost rises above a threshold, export as an OpenLineage facet.",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "keywords": [
        "dbt",
        "finops",
        "snowflake",
        "bigquery",
        "ci"
      ]
    },
    {
      "@type": "SoftwareSourceCode",
      "@id": "https://github.com/elindstrom/skewfinder",
      "name": "skewfinder",
      "codeRepository": "https://github.com/elindstrom/skewfinder",
      "programmingLanguage": "Scala",
      "license": "https://spdx.org/licenses/MIT.html",
      "dateCreated": "2019-09-30",
      "dateModified": "2025-12-02",
      "description": "Reads Spark event logs and names the stages where a handful of tasks dominate runtime. Suggests a concrete remedy for each case, salting, broadcast join or repartitioning, together with the expected effect.",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "keywords": [
        "spark",
        "performance",
        "data-skew",
        "observability"
      ]
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-nordicshield",
      "name": "Nordic Shield Insurance AB",
      "description": "Property and casualty insurer with around 6,400 employees, headquartered in Stockholm."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-nordmark",
      "name": "Nordmark Analytics AB",
      "description": "B2B SaaS vendor for product analytics, around 400 employees, headquartered in Stockholm."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-fjall",
      "name": "Fjäll Mobility AB",
      "description": "Carsharing and micromobility operator in eleven Nordic and European cities."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-nordicfreight",
      "name": "Nordic Freight Systems AB",
      "description": "Freight forwarding and contract logistics company with its own telematics fleet."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-sveabank",
      "name": "Svea Bank Group AB",
      "description": "Regional bank with a corporate banking business in Sweden."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-skandiaretail",
      "name": "Skandia Retail Group AB",
      "description": "Grocery retailer operating around 900 stores across Sweden."
    }
  ],
  "x-meta": {
    "origin": "https://eriklindstrom.dev",
    "defaultLanguage": "en",
    "profileType": "person",
    "profileRole": "data-engineer",
    "jobSeeking": true,
    "portraitPath": "/portrait.jpg",
    "ogImagePath": "/og-image.jpg",
    "languages": [
      {
        "code": "en",
        "locale": "en_US",
        "schemaLocale": "en-US",
        "label": "English",
        "homePath": "/",
        "blogPath": "/blog"
      }
    ],
    "keywords": "data engineering, streaming, Apache Iceberg, Kafka, dbt, data contracts, lakehouse, Erik Lindström",
    "titles": {
      "en": "Senior Data Engineer – streaming, lakehouse, data quality"
    },
    "bios": {
      "en": "Erik Lindström builds data platforms for regulated, data-intensive environments. Focus: streaming, Iceberg lakehouses, data contracts and what a pipeline actually costs."
    },
    "slogans": {
      "en": "A pipeline is only finished when somebody else can fix it at three in the morning."
    },
    "longBio": {
      "en": "I came to data engineering through classic data warehousing, back when batches ran overnight and somebody checked the numbers in the morning to see whether they looked plausible. What I took from that is a healthy respect for data quality. What I have learned since is that most problems in data platforms are not technical problems at all, they are contract problems: nobody wrote down who delivers which data with which guarantee. So when I start on a new platform I begin with the interfaces between teams, not with the tooling. Technically I am happiest with Kafka, Flink, Iceberg, dbt and Python, but the tools are interchangeable. What is not interchangeable: idempotency, traceability, visible cost, and the ability to re-run a load without being afraid of it."
    },
    "blogNames": {
      "en": "Late Arriving Facts"
    },
    "social": {
      "linkedin": "https://www.linkedin.com/in/erik-lindstrom/",
      "github": "https://github.com/elindstrom",
      "substack": "https://elindstrom.substack.com/",
      "mastodon": "https://mastodon.social/@elindstrom"
    }
  },
  "x-availability": {
    "status": "open_to_offers",
    "earliestStart": "2026-11-01",
    "noticePeriodMonths": 3,
    "employmentTypes": [
      "FULL_TIME",
      "PART_TIME"
    ],
    "minimumWeeklyHours": 32,
    "workModel": "remote-first",
    "onsiteWillingness": "up to 5 days per month, preferably in one block",
    "willingToRelocate": false,
    "baseLocation": "Stockholm, SE",
    "targetRoles": [
      "Staff Data Engineer",
      "Data Platform Engineer",
      "Lead Data Engineer",
      "Principal Data Engineer"
    ],
    "salaryExpectationSEK": {
      "min": 1050000,
      "target": 1200000,
      "currency": "SEK",
      "period": "P1Y"
    },
    "preferredIndustries": [
      "Insurance",
      "Logistics",
      "Energy",
      "B2B SaaS",
      "Public sector"
    ],
    "dealbreakers": [
      "On-call rotation with no time left for structural improvement",
      "A data platform with no counterpart on the business side",
      "Full-time office attendance"
    ]
  },
  "x-github": {
    "handle": "elindstrom",
    "profileUrl": "https://github.com/elindstrom",
    "followers": 1840,
    "repositories": [
      {
        "name": "backfill-guard",
        "url": "https://github.com/elindstrom/backfill-guard",
        "language": "Python",
        "stars": 1247,
        "forks": 96,
        "openIssues": 14,
        "license": "Apache-2.0",
        "created": "2021-03-14",
        "lastCommit": "2026-07-28",
        "topics": [
          "airflow",
          "dagster",
          "idempotency",
          "backfill",
          "data-quality"
        ],
        "description": "Stops backfills from writing the same partition twice. Watermark registry, partition locks and a dry-run mode that shows which windows would be overwritten.",
        "highlights": [
          "Adapters for Airflow, Dagster and plain cron setups",
          "Locking through Postgres advisory locks or Redis, whichever the team already runs",
          "According to the issue tracker, in use at at least four companies with more than 1,000 DAGs"
        ]
      },
      {
        "name": "pg2iceberg",
        "url": "https://github.com/elindstrom/pg2iceberg",
        "language": "Go",
        "stars": 2903,
        "forks": 211,
        "openIssues": 37,
        "license": "MIT",
        "created": "2022-11-02",
        "lastCommit": "2026-08-05",
        "topics": [
          "cdc",
          "postgresql",
          "iceberg",
          "lakehouse",
          "golang"
        ],
        "description": "PostgreSQL logical replication straight into Apache Iceberg, no Kafka in between. Exactly-once through Iceberg snapshots, additive schema evolution, resume from the last LSN.",
        "highlights": [
          "Around 180,000 row changes per second on a mid-sized instance",
          "Survives a dropped replication slot without a full reload",
          "Configurable compaction so small files do not take over the table"
        ]
      },
      {
        "name": "dbt-costlens",
        "url": "https://github.com/elindstrom/dbt-costlens",
        "language": "Python",
        "stars": 764,
        "forks": 58,
        "openIssues": 9,
        "license": "Apache-2.0",
        "created": "2023-06-19",
        "lastCommit": "2026-06-11",
        "topics": [
          "dbt",
          "finops",
          "snowflake",
          "bigquery",
          "ci"
        ],
        "description": "Per-model cost transparency in the pull request, with budgets per folder and a comparison against the previous week.",
        "highlights": [
          "GitHub Action that posts a comment on the PR",
          "Adapters for Snowflake, BigQuery and Databricks SQL",
          "Exports an OpenLineage facet for downstream lineage tools"
        ]
      },
      {
        "name": "skewfinder",
        "url": "https://github.com/elindstrom/skewfinder",
        "language": "Scala",
        "stars": 411,
        "forks": 44,
        "openIssues": 6,
        "license": "MIT",
        "created": "2019-09-30",
        "lastCommit": "2025-12-02",
        "topics": [
          "spark",
          "performance",
          "data-skew",
          "observability"
        ],
        "description": "Analyses Spark event logs and shows which stages are waiting on individual tasks, with concrete remedies and an estimated effect.",
        "highlights": [
          "Detects skew without adding instrumentation to the job",
          "One HTML report per application",
          "Usually the first thing reached for when a performance ticket lands"
        ]
      },
      {
        "name": "duckhouse-notes",
        "url": "https://github.com/elindstrom/duckhouse-notes",
        "language": "Jupyter Notebook",
        "stars": 288,
        "forks": 31,
        "openIssues": 2,
        "license": "CC-BY-4.0",
        "created": "2024-02-08",
        "lastCommit": "2026-05-19",
        "topics": [
          "duckdb",
          "iceberg",
          "benchmark",
          "notes"
        ],
        "description": "Reproducible notebooks on the question of when a distributed warehouse beats DuckDB on one large machine. Scripts, raw data and the places where the answer is inconvenient."
      }
    ]
  },
  "x-cv": {
    "headings": {
      "en": "Roles and projects"
    },
    "intro": {
      "en": "Around 15 years of data work: nightly batches in retail, real-time telematics, and a lakehouse migration carried out in production. References for individual roles on request."
    },
    "presentLabel": {
      "en": "today"
    },
    "entries": [
      {
        "organization": [
          "Nordic Shield Insurance AB"
        ],
        "period": {
          "start": "2024-06",
          "end": null
        },
        "role": {
          "en": "Senior Data Engineer and Tech Lead, Data Platform"
        },
        "summary": {
          "en": "Built the claims data platform of an insurer: CDC from 14 policy systems, audit-proof historisation and a deletion process that carries GDPR requests verifiably through every layer."
        },
        "stack": [
          "Debezium",
          "Kafka",
          "Apache Iceberg",
          "Trino",
          "dbt",
          "Terraform",
          "AWS"
        ],
        "details": {
          "en": [
            "Replaced 41 nightly extraction jobs with change data capture from 14 policy and claims systems, bringing the availability of current claims data from T+1 down to under 15 minutes",
            "Designed a bitemporal historisation that separates business validity from technical load time, because claims get corrected retroactively and reporting still has to be reproducible",
            "Built the deletion process for data subject requests across the bronze, silver and gold layers, including an audit trail for the regulator and an automated check that deleted keys no longer appear in any materialisation",
            "Introduced data contracts between the policy system teams and the platform: schema, semantic changes and named owners are versioned, and a breaking change breaks the build rather than the reporting",
            "Cut Trino cost by 27 percent through a revised partitioning strategy, file compaction and switching off 60 materialisations that nobody had queried in over a year",
            "Technical leadership for four engineers without line management responsibility, with a weekly architecture review and a deliberately short decision log instead of lengthy concept documents"
          ]
        }
      },
      {
        "organization": [
          "Nordmark Analytics AB"
        ],
        "period": {
          "start": "2022-09",
          "end": "2024-05"
        },
        "role": {
          "en": "Staff Data Engineer"
        },
        "summary": {
          "en": "Migrated a grown Redshift warehouse to an Iceberg lakehouse without downtime while cutting platform cost by 38 percent."
        },
        "stack": [
          "Apache Iceberg",
          "Spark",
          "dbt",
          "Airflow",
          "Snowflake",
          "Python",
          "Kubernetes"
        ],
        "details": {
          "en": [
            "Migrated 2.1 petabytes of raw data and around 640 dbt models to Apache Iceberg, in waves per business domain rather than as one large cutover",
            "Ran both systems in parallel for seven months with automated result comparison: every migrated metric had to match the old system for 30 consecutive days before the old path was switched off",
            "Reduced platform cost by 38 percent, mainly by separating storage from compute, compacting small files and retiring models with no consumers",
            "Introduced dbt-costlens so that teams see the cost of their models in the pull request rather than in the platform's monthly bill",
            "Shortened the evening build on the critical path from 6 hours 20 minutes to 11 minutes, which made product reporting available before the working day started for the first time",
            "Built an onboarding path for new engineers: one week, one real model, one review, instead of four weeks of reading documentation"
          ]
        }
      },
      {
        "organization": [
          "Fjäll Mobility AB"
        ],
        "period": {
          "start": "2020-02",
          "end": "2022-08"
        },
        "role": {
          "en": "Lead Data Engineer"
        },
        "summary": {
          "en": "Built a carsharing company's data platform from scratch, including data contracts between product teams and analytics."
        },
        "stack": [
          "Kafka",
          "Flink",
          "BigQuery",
          "dbt",
          "Looker",
          "Terraform",
          "GCP"
        ],
        "details": {
          "en": [
            "Built the company's first data platform, moving from a collection of scripts running against production replicas to a platform with clear layers, tests and operational ownership",
            "Introduced data contracts between six product teams and analytics, with a schema registry, compatibility checks in the pipeline and a named owner for every event",
            "Built a real-time utilisation model per city district on Flink that drove vehicle redistribution and noticeably reduced empty approach trips",
            "Set up a self-service model in which business departments could contribute their own models in the analytics layer, reviewed by the platform team against binding naming and testing conventions",
            "Made data quality visible in a dashboard that did not show the number of passing tests but the number of affected decisions, which changed how much attention the business paid to it",
            "Grew two engineers from junior to mid level, including on-call duty with honest post-incident reviews rather than blame"
          ]
        }
      },
      {
        "organization": [
          "Nordic Freight Systems AB"
        ],
        "period": {
          "start": "2017-07",
          "end": "2020-01"
        },
        "role": {
          "en": "Senior Data Engineer"
        },
        "summary": {
          "en": "Real-time processing of telematics data from around 9,000 vehicles, from ingestion to arrival-time prediction in dispatching."
        },
        "stack": [
          "Kafka",
          "Kafka Streams",
          "Cassandra",
          "Spark",
          "Scala",
          "Grafana"
        ],
        "details": {
          "en": [
            "Ingested around 40,000 position and sensor events per second from roughly 9,000 vehicles, including handling coverage gaps and events arriving hours late",
            "Designed a processing path that places late events correctly instead of discarding them, because for a delivery what counts afterwards is when it actually happened",
            "Connected arrival-time prediction to the dispatching system, which let dispatchers see delays on average 40 minutes earlier",
            "Wrote skewfinder in response to recurring Spark jobs stuck on a few overloaded partitions, later released as open source",
            "Built monitoring that showed business gaps rather than system metrics: missing vehicles, implausible jumps, silent data sources"
          ]
        }
      },
      {
        "organization": [
          "Svea Bank Group AB"
        ],
        "period": {
          "start": "2014-04",
          "end": "2017-06"
        },
        "role": {
          "en": "Data Warehouse Engineer"
        },
        "summary": {
          "en": "Regulatory and risk reporting, moving from nightly full loads to incremental processing."
        },
        "stack": [
          "Oracle",
          "PL/SQL",
          "Informatica",
          "Python",
          "Hadoop",
          "Hive"
        ],
        "details": {
          "en": [
            "Owned the pipelines behind regulatory reporting, where traceability matters more than speed and every figure has to be explainable back to its source",
            "Converted core load paths from full loads to incremental processing with change detection, which shrank the nightly window from 7.5 hours to 2 hours",
            "Built a reconciliation layer between the core banking system and the warehouse that surfaced differences automatically instead of at quarter end",
            "Documented the business lineage of every reported figure, which was used as evidence in two audits",
            "First exposure to Hadoop and Hive for analyses that no longer ran at acceptable cost in the relational warehouse"
          ]
        }
      },
      {
        "organization": [
          "Skandia Retail Group AB"
        ],
        "period": {
          "start": "2011-10",
          "end": "2014-03"
        },
        "role": {
          "en": "Working Student and Junior BI Developer"
        },
        "summary": {
          "en": "First production pipelines in retail: SSIS, sales reporting and the realisation that Excel exports are an architecture topic."
        },
        "stack": [
          "SQL Server",
          "SSIS",
          "SSRS",
          "T-SQL",
          "VBA"
        ],
        "details": {
          "en": [
            "Developed and operated SSIS packages for sales and inventory reporting across around 900 stores",
            "Replaced 23 grown Excel analyses with standardised reports, after talking to the people who actually used them",
            "Built a simple plausibility check for store submissions that surfaced missing or duplicated daily closings before reporting ran",
            "Wrote a master's thesis on the consistency guarantees of log-based replication alongside the job"
          ]
        }
      }
    ],
    "detailsLabel": {
      "en": "Details"
    }
  }
}

I see many tools out there claiming that they monitor ai search results and helping you grow. Honestly I think it's too much noise.

Can you recommend one or two tools that are actually legit?

Saw that Google is now showing AI-generated images inside AI Overviews, and it got me thinking.

If Google can summarize a page AND generate the visuals needed to answer the query, what’s left to make someone click through to the original site?

I feel like the SEO conversation is slowly shifting from “How do I rank #1?” to “How do I actually give people a reason to leave Google and visit my site?”

Curious how you guys are thinking about this.

Are you already changing your SEO/content strategy because of AI Overviews?

Hi everyone,

There seem to be two fundamentally different ways AEO platforms measure AI visibility. Here is my summary of how AEO platforms measure brand mentions, citations, and competitive positioning. If you have a different understanding or you have seen AEO platforms take a different approach that I may not be aware of, share it.

The focus is measuring brand mentions and citations, not other capabilities around additional AEO features - LLM bot traffic analysis, etc.

Method #1: Custom prompt measurement

There are a lot of AEO platforms that use this method. Peec, Otterly, Adobe Brand Visibility, LLM Pulse, etc. You create a set of prompts for your brand to measure your brand presence. For instance, "What is the best bike to buy for a 6 year old learning to ride a bike?" The platform executes that set of prompts against the AI platform it is measuring, typically daily, and then analyzes the resulting response for things such as:

• Was the brand mentioned?
• Which competitors were mentioned?
• Where in the response did the brand appear?
• What domains/pages were cited?
• Was the brand's own website cited?

For ChatGPT in particular, the Responses API may be used by the AEO platform to execute these prompts and receive a response to store and analyze (though the AEO platforms typically don't reveal the exact LLM API they are using in their documentation).

Limitations: Because the AEO platform is executing a controlled prompt rather than observing a real user's session, it lacks some of the implicit context a real user may bring — precise location, time-sensitive context, prior conversation history, personalization, etc. Some platforms allow country/region/location to be configured explicitly.

Method #2: Clickstream / user opt-in data sets

Some larger AEO platforms like Semrush and Profound have invested in acquiring huge data sets from clickstream providers like Datos (owned by Semrush, now Adobe) or other methods. They are harvesting this data from real participants who allow these data gatherers to observe their browsing and anonymize their data.

For LLM interactions, they capture the users' real prompts and the LLM responses, then cluster / normalize the prompts to semantic topics or user intents. In this way, different prompts that users submit can be grouped together, and the responses can be captured, stored, and analyzed for brands, product names, citation links, etc.

This method is very different from the first method where brands curate a set of prompts that represent the space they want to measure their brand presence for.

Limitations: The clickstream data approach is valuable for directional market intelligence, but not ground truth for brand visibility.

1. Panel bias - even though the data providers have a large pool of millions of users, their data may not represent your core audience, particularly if you are in a specialized field or a B2B space. e.g. It probably represents moms looking for their kid's first bike better than an AI architect looking for the NAND device with the highest storage density.
2. Topic / prompt clustering - the process to distill clickstream data into measurable intelligence loses a lot of the nuance of individual prompt measurement.
3. Observed demand ≠ business value. Clickstream popularity doesn't always equal business value. For instance, a highly specialized AI infrastructure purchasing question may have tiny observed volume but influence a multimillion-dollar purchase. Custom prompt measurement is much better suited to measuring a customer's journey from discovery to conversion.

Method 2.1: Search-demand-derived prompt modeling

This is an alternate on Method 2, specifically used by Ahrefs (and maybe others). Rather than relying on observed AI-user prompts, Ahrefs uses its traditional keyword database and People Also Ask data to identify real search demand, converts those questions into conversational prompts, executes them against AI platforms, and captures the responses. I place this as a variant on method 2 because the method is still creating a large database, just leveraging search demand data rather than user observation data.

Limitations: Real search demand doesn't necessarily equal real LLM prompt demand. The tradeoff is that this approach inherits assumptions from traditional search behavior. Real Google search demand can be a useful proxy for user interest, but it may not reflect how people naturally formulate questions in conversational AI.

Summary

Both methods 1 & 2 bring valuable insights to a brand as a part of a strong AI visibility program, and ideally a brand will use tools and either an internal team or an agency leveraging both methods. Some tools and agencies have capabilities from both visibility measurement methods, whereas others may only use one method.

Want to sanity-check how the community thinks about the structure of a real SEO analysis service today. The problem is that most of what agencies and freelancers sell under that name is basically the 2019 checklist with AI bolted onto the title.

Here's my list of what I think should be in a modern one, and I want to hear where I'm wrong or what I'm missing:

Classic technical audit

Crawlability, indexation, Core Web Vitals, mobile-first, hreflang, canonicals, structured data. It's the base without which nothing else matters. But it's not a differentiator anymore - anyone with a decent tool (SE Ranking, Screaming Frog, Ahrefs) can produce this.

AI search visibility analysis

This is where most people still aren't digging properly. You need to show the client where they stand across ChatGPT, Perplexity, Gemini, AI Overviews, AI Mode. Who mentions them by brand, where their domain gets cited as a source, where they're completely absent. It's not a bonus anymore, it's the foundation of the 2026 conversation, and if it's missing from the analysis the service is outdated.

Entity analysis and topical coverage

Not just a keyword list, but how the domain covers the topic through the lens of entities. Who are your competitors by entities (not by keywords), which entity gaps need to close before you have a shot at LLM citation.

Content quality audit through the LLM-friendliness lens

How structured is the content so LLMs can extract facts from it. Headings, lists, comparison tables, clean definition-style paragraphs. Content without this structure doesn't make it into AI Overviews even when it ranks top 3.

Backlink profile analysis with a focus on AI-relevant sources

People used to just count DA/DR. Now what matters more is whether the sites linking to you get cited by LLMs themselves. A link from a site ChatGPT recommends in your niche is worth dozens of links from random blogs.

SERP feature and intent analysis

Featured snippets, People Also Ask, image packs, video carousels, AI Overviews. The distribution of traffic across SERP features rewrites the whole strategy.

Competitor delta

Not just

>here are the top 10 competitors by visibility

but what they're actually doing differently and which of their tactics are genuinely working.

First-party client data

GSC, GA4, CRM, conversion data. An SEO analysis service without integration into real business data is guesswork. Why rankings dropped or grew — you can only answer that when you see the full picture.

Practical action plan with prioritization

Not an 80-page report but 15 concrete actions sorted by ROI. The client doesn't need a dissertation, they need to know what to do Monday morning.

What am I missing? What's overkill?

Especially curious to hear from people who sell SEO analysis service as a productized offering.

Great news - SEJ's u/rustybrick just shared on X today:

>
The Google Search Console generative AI performance reports seem to be live for everyone now. Google has not yet announced the full rollout of the generative AI performance reports but after checking all my profiles in Search Console, it seems to now be fully live.

>Yes, Google did expand access to this report a few weeks ago, but now it seems to be available for everyone. The report still does not include any click data or query data but it is fully live for all.

>Some are saying they do not see it, but I checked around 25 profiles I have access to and all of them have it. Google does say it won't show the report if, "Your site hasn't received enough impressions in generative AI features on Google Search."

Also in the post is a screenshot of how to see where to find the Google Generative AI Performance Report

I’m the CMO at a Series A funded SaaS startup. We’ve been investing a lot of time and money into PR to increase brand awareness. Those efforts are clearly generating results as far as getting news coverage and other earned media placements.

The thing I’m less sure about is how LLMs like ChatGPT are representing our brand when people ask questions on those platforms. I’d also like to create a feedback loop that allows me to see how our PR efforts are influencing the narrative in ChatGPT over time.

Right now I'm mostly checking manually every so often, which isn't exactly scalable. What are you using to track this across AI search? Ideally I'd like to compare how our visibility changes over time.

Hello All,

Generative ai report is now available in search consoles from today in all regions. It shows impressions only. I think the existing data is helpful as something is better than nothing.

I need an opinion on it that is really helpful and how?

What do you think, what needs to add in it?

Thanks

I follow Lily Ray, and today I saw this:

https://preview.redd.it/lnjb2m2wntih1.png?width=780&format=png&auto=webp&s=ffbc17b39769c149b910c1f3739396deb93547d4

I thought this was a done deal already. And now people are talking about it again from the SEO context: Can the search engines detect it? Well, they can, but doing something about it is something different altogether.

I've written about this in the past:

https://kafkai.ai/articles/ai-seo/ai-content-detection-fails/ and https://kafkai.com/en/blog/detecting-ai-generated-text-a-look-at-the-challenges-and-mitigations/

And of course, the whole world is much bigger than Claude.

Hey everyone,

I’m building a small custom GEO dashboard and I’m trying to understand how people collect AI search results.

Right now I’m using DataForSEO, but the ChatGPT and Gemini data seems to come through APIs.

What I’m looking for instead is data from the actual user interface. basically the same results a real user would see on ChatGPT, Gemini, AI Mode, etc., including citations/sources if possible. (As software like Bluefish, Profound, PeecAI etc..)

Has anyone found a good way to collect this at scale?

Are you using browser automation, a third-party service, your own scraper, or something else?

Would be really interested to hear what people are using.

Thanks all !